Float that initializes to NaN

**phantomotap** · 05-16-2012

It is easy to just ignore the rest of what you are writing when you start your post with two quite provoking/disparaging statements; you know that, right?

It is quite easy to write a newbie who says that some of his code "shouldn't generate any error" off as a fool or troll after having the error explained yet here I am still offering support.

Being a newbie, your opinions regarding how a C++ compiler should behave in relation to the standard is irrelevant. You don't like that? I don't care. Once you have more experience with why the code we are discussing is wrong you'll understand why it must be the way it is.

I don't think that the statement "base_safe_float<float> shouldn't generate any error here" is wrong; I know for a fact that it wrong; it is not an opinion. You don't like that? You'll just have to get over it; if you are going to be a programmer you'll always not understand a lot of things.

Apparently my compiler could chose between the two cases and that is actually what matters to me.

Your compiler did no such thing. The conversion between `int' to `float' or `float' to `int' isn't at all the same situation. The compiler has rules to choose between those when considering an implicit conversion that form a "best fit" situation.

If it behaves in one way for float it should behave in the same way for the class I'm creating.

No. It should not; I've told you why.

I don't know what is correct behavior and which is not (which you seems to know), but I don't want it to change it when I switch type.

Then do what I told you to do and explicitly cast the zero result (preferably by `static_cast') of a `typedef'.

Soma

**phantomotap** · 05-16-2012

It is easy to just ignore the rest of what you are writing when you start your post with two quite provoking/disparaging statements; you know that, right?

It is quite easy to write a newbie who says that some of his code "shouldn't generate any error" off as a fool or troll after having the error explained yet here I am still offering support.

Being a newbie, your opinions regarding how a C++ compiler should behave in relation to the standard is irrelevant. You don't like that? I don't care. Once you have more experience with why the code we are discussing is wrong you'll understand why it must be the way it is.

I don't think that the statement "base_safe_float<float> shouldn't generate any error here" is wrong; I know for a fact that it wrong; it is not an opinion. You don't like that? You'll just have to get over it; if you are going to be a programmer you'll always not understand a lot of things.

Apparently my compiler could chose between the two cases and that is actually what matters to me.

Your compiler did no such thing. The conversion between `int' to `float' or `float' to `int' isn't at all the same situation. The compiler has rules to choose between those when considering an implicit conversion that form a "best fit" situation.

If it behaves in one way for float it should behave in the same way for the class I'm creating.

No. It should not; I've told you why.

I don't know what is correct behavior and which is not (which you seems to know), but I don't want it to change it when I switch type.

Then do what I told you to do and explicitly cast the zero result (preferably by `static_cast') of a `typedef'.

Soma

**iMalc** · 05-17-2012

Something like this:

Code:

#ifndef NANFLOAT_H
#define NANFLOAT_H

#include <cmath>
#include <iostream>

template<typename T> class nanInit {
	T value;

public:
	nanInit() : value(sqrt(T(-1))) {} // I would optimise out the sqrt call in practice.
	nanInit(T inVal) : value(inVal) {}

	operator T() const { return retVal; }

	nanInit& operator +=(const nanInit &a)
	{ return *this = value + a; }
	nanInit& operator -=(const nanInit &a)
	{ return *this = value - a; }
	nanInit& operator *=(const nanInit &a)
	{ return *this = value * a; }
	nanInit& operator /=(const nanInit &a)
	{ return *this = value / a; }

	friend std::ostream& operator << (std::ostream &os, const nanInit &a)
	{ return os << a.value; }
	friend std::wostream& operator << (std::wostream &wos, const nanInit &a)
	{ return wos << a.value; }

	friend std::istream& operator >> (std::istream &is, nanInit &a)
	{ return is >> a.value; }
	friend std::wistream& operator >> (std::wistream &wis, nanInit &a)
	{ return wis >> a.value; }

	const nanInit operator + () const
	{ return *this; }
	const nanInit operator - () const
	{ return static_cast<nanInit>(-value); }

	const nanInit operator++ (int) {	// Post Increment operator
		nanInit result = *this;
		++*this;
		return result;
	}
	const nanInit& operator++ ()	// Pre Increment operator
	{ return *this = value+1; }
	const nanInit operator-- (int) {	// Post Decrement operator
		nanInit result = *this;
		--*this;
		return result;
	}
	const nanInit& operator-- ()	// Pre Decrement operator
	{ return *this = value-1; }
};

#endif

To the best of my knowledge, this is everything you need and nothing you don't.

**iMalc** · 05-17-2012

Aw nuts, I forgot the #ifdef DEBUG part around the constructor initialisation list of the default constructor.

**then** · 05-17-2012

phantomotap, I appreciate your support and you might be right about what you say, but if you want to help people you can't start by offending them.

Originally Posted by iMalc

Something like this:

*Code*

To the best of my knowledge, this is everything you need and nothing you don't.

Thanks, it looks great. I haven't got time to try it out now, though, but I will definitely do it later.

**phantomotap** · 05-17-2012

To the best of my knowledge, this is everything you need and nothing you don't.

Using two implicit conversions to implement the mathematics assignment operators is really freaking weird.

If you are going that far in the effort you can pretty much get the same behavior by change the implicit conversion to a reference and adding one for the constant reference.

if you want to help people you can't start by offending them

O_o

That's somewhat interesting but I didn't start off in any way that could possibly be considered offensive.

Soma

**iMalc** · 05-18-2012

Originally Posted by phantomotap

Using two implicit conversions to implement the mathematics assignment operators is really freaking weird.

Yeah I guess it is. I had another class which made heavy use of the conversions because it needed to, and leaving them implicit seemed tidier in that case.
In this case though, I should have used a.value directly.

Oh and I changed my mind about the #ifdef part, it would of course be far better to put the conditional compilation macro around the typedef that either uses this template or a float directly.

**then** · 05-22-2012

I tried your class, iMalc, and everything seems to work like it does for floats or doubles, except from the ?: operator, just like for the class I defined.

Also, I had to change the return value for the conversion operator to value, since it returned retVal which was undefined. And to generate a NaN, on all machines that support IEEE floating point there is a macro defined in <math.h> called NAN that will do that (maybe that is what you would use in practice).

As of the problem with the ?: operator: I have the following code

Code:

ftype a = MIN(b - c, d);

where b, c and d are ftype objects, where ftype is defined as

Code:

typedef nanInit<float> ftype

and MIN is a macro defined as

Code:

#define  MIN(x, y)  ((x) <= (y) ? (x) : (y))

However, the code won't compile, and the message I'm getting from the compiler is:

Code:

error: operands to ?: have different types 'double' and 'pftype'

Converting d to float works but is bad, because the definition of ftype may change.

I may instead convert b - c back to ftype, so I have

Code:

ftype a = MIN(ftype(b - c), d);

which is better, because that code is independent of the definition of ftype.

However, my project is quite small and I have already had to change on 21 places in the code just becase I changed the definition of ftype from float to nanInit<float>. For larger projects, there could be a lot more work than this that would be necessary just for changing the typedef of ftype (or a corresponding typename), which kind of feels unnecessary. Is there really no way to get around this problem?

**iMalc** · 05-22-2012

I think this has already been somewhat covered. You need to provide arguments that are the same type to ?:

**then** · 05-22-2012

I don't understand. I know Soma said that too, but I didn't have to provide arguments of the same type when ftype was defined as float, since I provided it with a float and an int and it worked. What's the difference here?

Thread: Float that initializes to NaN

Thread Tools

Search Thread

Display

Similar Threads

(float) or (float*) wrt sizeOf()

float value

error C2664: cannot convert parameter 1 from float** __w64 to float *

initializes all components of failing to false

Unresolved external 'convert(float, float)'

Tags for this Thread