[Verse-dev] About NAN and various REAL_MAX

[eskil at obsession.se]

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.

>> It think there are four paths we can go here:
>>
>> 1: don't change anything.
>>
>> Con: It can be conceived as "ugly".
>> Con: It takes away a conceivably useful value.
>> Pro: It works.
>> Pro: No one has ever complained about the cons.
>
> Except of course the people who can't compile Verse-Blender, since Verse
> doesn't build, due to the too large float constant causing a parse error
> with some versions of the Microsoft compiler.

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

>> 2: use NAN
>>
>> Pro: Pretty.
>> Con: Complicates the API.
>
> How? By requiring that users don't send NANs? Is that more complicated
> than requiring that users don't send the MAX?

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

>> Con: Assumes the user knows how NANs work (they don't).
>> Con: Substantial app re-write.
>
> 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.

>> Con: Easy to inadvertently send wrong command.
>
> Define "easy". Do you find your math code often ends up with a NAN? I don't
> think I've ever seen it, and still considered the code to work ... Creating
> a NAN is fairly hard, in my experience.

I have done it many, many times. Especially during the development of Loq.

>> 3: use NAN internally, but don't expose in API
>>
>> Pro: Pretty.
>> Con: Removes essential feature form verse.
>
> It's a feature I've never seen documented anywhere, and one that is not
> obviously ours to supply.

If its not documented well, that's a documentation problem.

>> Con: Substantial app re-write.
>> Con: Easy to inadvertently send wrong command.
>
> I disagree on the "easy" part. It becomes possible, which might bad bad
> enough.

see above.

>> Con: Since not exposed, hard to debug above problem.
>
> We could warn about it, if we were ready to spend the cycles to test for
> NANs coming in.

That would make command packing very ugly.

>> 4: use NAN internally, and MAX_FLOAT in the API
>>
>> Con: It can be conceived as "ugly"on the outside.
>
> We would not *use* MAX for anything on the outside, would we? Or do you
> mean that a vertex_set should look for MAX in the inputs, and if found
> become a vertex_delete, with NANs in the network? Sounds weird, so prob-
> bably that's not what you mean. :)

Command pack would use NAN, but MAX_FLOAT would still be reserved for users.

>> Con: It takes away many conceivably useful values.
>
> Huh? My demo implementation reserved exactly *one* NAN. That leaves a few
> million.

Example 4: would take away both a NaN and MAX_FLOAT

>> Con: Easy to inadvertently send wrong command.
>> Con: Since not exposed, hard to debug above problem.
>
> Perhaps, not sure I follow this case well enough though.
>
>> Sorry in my mind 1 still wins. Pretty is nice, but not important
>> compared to real problems and features.
>
>> 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 prob-
> lem, 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.

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.

Cheers

E