Re: NaN (was: Re: The Undefined Country (was Re: Quest: real world "Lua array with holes" usage))

[Dirk Laurie <dirk.laurie@...>]

2016-07-25 9:03 GMT+02:00 steve donovan <steve.j.donovan@gmail.com>:
> On Mon, Jul 25, 2016 at 2:26 AM, Soni L. <fakedme@gmail.com> wrote:
>> This is why we need NaN to be a falsey value. It shares many properties with
>> nil:
>
> Part of me really likes this idea

Can't agree. It's even weirder than the idea that 'false' should be the only
false value.

NaN is a slightly misleading term. It's only "not a number" when you view
floating-point numbers as a subset of real numbers. It _is_ a floating-point
number in the ubiquitous IEEE 754 standard, though. All arithmetic and
comparison operators are defined for it. It is only available in Lua as the
result of an arithmetic operation. It means "this operation has been tried,
and the result is not a real number, or ±Inf".

The fact that it cannot be used as a table index is a consequence of those
properties. because it will never test equal to any key in the table. Why not?
Because numbers test according to the rules of equality, but NaN does not
test equal to itself.

Using NaN for any purpose outside the context of floating point is a hack.
Hacks are disreputable. They must not be given respectabilty. Just as there
should be a clearly visible "is_nan" when you test whether a value is NaN,
there should be a clearly visible 'is_undefined' whenever you are using the
hack of letting "not(y) or isnan(y)" mean undefined.

People who use NaN in its natural sense should not be inconvenienced
in order to pander to those who use it as a hack. In a table of memoized
function values, nil should mean 'has not been computed' and NaN
should mean "has been computed, and the result was NaN". It should
not be necessary to rewrite an idiom like

   return y[n] or recompute(n,y)

just because suddenly NaN is falsey.