[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: Some small requests for the next release**
**From**: nt <niklas@...>
**Date**: Mon, 28 Feb 2005 12:20:24 -0400

`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.
`