Re: Some small requests for the next release

[nt <niklas@...>]

NaN's are extremely useful for dealing with missing data as one can 
avoid large numbers of existence checks. For example:
     a,b,c = GetFromDatabase("a", "b", "c")
     d = a + b/c
     if d == d then return "invalid" end
is much clearer than putting a lot of if-then checks on the 
GetFromDatabase results provided that GetFromDatabase() can return NaN. 
Using zero for missing data is problematic as division  won't return a 
consistent value and it is often a legit value in and of itself. NaNs 
propagate nicely through arithmetical calculations and have many of the 
semantics of SQL NULL values.  Putting aside all the divisions of 
opinion in the SQL community about the validity of having NULLs in the 
first place, I find that NaNs make numeric code in the presence of 
missing values easier to write and to understand.  Clearly code that 
expects the NaN behaviour will not run if Lua is compiled with integer 
numbers, but then again most of the math library will not either... 
Given that math.pi is provided, it would be nice to round out the 
collection of standard constants.

niklas

> nan = tonumber"nan" will do, it's not very non-portable.  On an IEEE 
> conforming system this will generate a NaN.  On systems without NaNs 
> then it will generate 0.  Seems like a reasonable behaviour.  You can 
> even do [[ if nan == nan ]] to see which one you ended up with.
>
> Why would anyone anyone want math.nan anyhow?  Surely they get 
> generated naturally as the result of ordinary computation.