lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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.