Up to this point, I've never really done anything that could potentially have these as results (if the code was debugged or handled the exceptions right).
Enter geometry and having to deal with the possibility of infinite slope, which have situations where division by 0 can happen and must somehow be stored.
As far as I have been able to tell, these are IEEE 754 floating point standard but only for C99 (and possibly GNUC specific?)
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
The more I think about this, the less I like the idea of this.
Maybe I'll just add some extra flag to a struct, use a macro to check for weird values within the struct, and if in some future date some real solution that can be expected to operate properly on any platform, just change the definition of the macro.
After reading up more and more on this, the solutions all look essentially terrible.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker wrote:The more I think about this, the less I like the idea of this.
Yeah I don't like it either, for me the NaN and infinities are more like error results rather than genuinely useful values, and any code that uses them may suffer portabilities problems (portability to different Oses, different compilers or different languages).
I'll probably make functions that return pointers and then the returned pointer can check and see if it is a special address being pointed to. That keeps things in the "if (result == NULL)" family.
I read that the behavior of floating point return values for special cases can vary per-processor. Intel, AMD, RISC (game consoles), MIPS (PSP), ARM (mobile). So ... is mess to avoid ... yes. This is without bringing up compiler compatibility, etc.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
First, I agree: best to avoid using nan and inf. They seem to be best for indicating bad input (and to a certain extent, the nature of the badness).
One problem with nan is nan is never equal to anything, even nan (ie, comparison always fails).
Inf is sort of useful: you can compare against it (so it's good for initializing min/max (you have + and - inf)), but that's about it. Forget doing any actual math with inf. I had the bright idea of using inf for initializing windings in qf's bsp compiler. Worked wonderfully for min/max but broke completely for clipping.