Re: NaNs etc. once again. Was: Re: 5.1 and vc6

[Shannon Stewman <stew@...>]

On Sat, Mar 05, 2005 at 12:55:32PM -0500, Rici Lake wrote:

> ideally, that using nil in an arithmetic operation has the same result
> as if it were NaN. This would allow programs to test for NaN in a
> reasonably obvious way, and also allow arithmetic functions to return a
> NaN-like object, without much dependency on the underlying
> architecture.

Your first suggestion would make it hard to track down dumb bugs in
numerical code.  The presence of NaN usually tells me one of two
things:

1. I divided by zero somewhere

2. I gave a function an invalid number (e.g., took the square root of
   an negative number)

Sometimes, in large simulations, these two conditions are hard enough
to track down.  Allowing (1 + nil) --> NaN would add an unrelated
error.  Typically I encounter (1 + nil) when I've mistyped a variable,
field name, or table key name.  The overlap of these two error
conditions would increase my debugging heachace considerably.

nil and NaN are distinct concepts, and I think they should be kept so.

Best,

-- 
Shannon Stewman         | Let us walk through the waning night,
Caught in a whirlpool,  | As dawn-rays tickle our toes, the dew soothes
A quartering act:       | Our blistered soles, and damp bones stir
Solitude or society?    | As crimson cracks under the blue-grey sky.