[Verse-dev] About NAN and various REAL_MAX

[Emil Brink]

eskil at obsession.se wrote:
> Hi!
> 
>> Eskil sent this to me in private, but since it's in English I guess it's
>> for the list so I forwarded it there.
> 
> Yes, sorry about that.

No problem, I do it all the time, but are trying to learn to look out for
it. :)

[...]
> Different issue. One issue is what to reserve. An other is how to define 
> it. Nan is even harder to define then MAX_FLOAT.

Well, a bit harder perhaps, but I don't quite see what is so hard about
the solution I've shown previously.

[...]
> Its more complicated since you cant just have a single define that you 
> ban both use for assignment and to compare with.

Well, if that is a requirement, then yes I guess.

[...]
>> I don't believe it is. I would volunteer to do the conversion on all our
>> code.
> 
> Don't assume you have assess to all source code using verse.

I didn't, which was why I said "our". But sure, other developers would
have to port their code themselves. I wonder how many applications use
our max float, though.

[NAN hard to generate]
> I have done it many, many times. Especially during the development of Loq.

Okay.

[undocumented feature]
> If its not documented well, that's a documentation problem.

True, I guess. There is no line-by-line documentation of the verse.h header
file; perhaps there should be.

[big snip]
>>> All platforms have the same IEEE floats. They all express MAX_FLOAT
>>> with the same bits. The difference is in how the compilers converts
>>> the numbers in to bits.
>>
>> Have you tested this? I agree that it makes sense for that to be the 
>> problem, but still, have you tested it?
> 
> No. but its kind of obvious. If you define a value and try to put it in 
> a double, and the compiler says it can be done, and then switch compiler 
> / OS and then fail to put the same number in a double, the hardware 
> didn't just loose its capability to store a specific combination of bits.

No, but it's conceivable that different platforms run the processor
in different modes, which might affect the bit patterns a little,
or something. At least I thought so, but I'm not sure. I guess it's safe
to assume, for now, that that is not the case.

> If you use the smaller MAX_FLOAT form the platform that thinks our 
> MAX_FLOAT is too big and compiles it on the platform that does take our 
> MAX_FLOAT do you get the same result? In that case we have a solution.

Haven't tested that. One annoying thing is that GCC doesn't have a problem
with excessive precision in floating point constants, the way the Microsoft
compiler seems to have.

Anyway, loading a float with the FLT_MAX constant and dumping the bytes
reveals that it's 0x7f7fffff, which makes sense from reading the Wikipedia
entry on IEEE 754 a bit.

So, I came up with the following pretty nice snippet to load this value
into a floating point variable:

float a = ((union { unsigned int x; float y; }) 0x7f7fffffu).y;

I believe this works, as long as

* unsigned int and float are both 32 bits
* the endianness for ints is the same as for floats ... I think this is
   the case on most "normal" platforms, but have only tested the above
   in Linux on x86
* the compiler understands the code at all :) GCC was pretty impressive
   here ...

That should be something we can put in a define, such as

#define V_REAL32_MAX (((union { unsigned int x; float y; }) 0x7f7fffffu).y)

I guess we can go by that solution, then. I'm less interested in fighting a
losing battle for using NAN for reasons of prettiness, than having the issue
resolved at all. The above needs more testing first, though.

Regards,

/Emil