Re: +-Inf and NaN

[Camm Maguire]

Greetings!

Raymond Toy <toy.raymond@gmail.com> writes:

> On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <camm@maguirefamily.org> wrote:
>
>  Greetings, and thanks to all for the very helpful feedback!
>
>  I'd also like to note in passing that the excellent SBCL out of the box
>  triggers an error, which we separately refer to as an 'exception trap',
>  when NaN is passed to the comparison functions, e.g. '=.  And low and
>  behold, gcl does the same when 'trapping' is turned on, but gcl turns
>  trapping off 'out of the box'.  NaN does not trigger an exception nor
>
> I hope you will consider changing the default to trap on invalid
> operations so that instead of returning NaN, an error is signaled.  I
> certainly hate this behaviour, because after you do a long set of
> numerical computations, all the results are NaN.  I've just wasted a
> whole bunch of time.  This is super-annying in Javascript where you
> don't have an option of disabling traps.  Now you get to go through
> all the code and either put prints or checks for NaN to see what
> caused it.  What a colossal waste of time when the computer could have
> told me.
>

This is good to hear, as I was of the opposite impression that most
users wanted NaNs to propagate freely.


>  error when passed to '+,'*,'cos etc. but returns NaN.  This is the
>  current state of play.  What follows is a discussion of what it means
>  and the best way to fit NaN into the common-lisp type lattice so it does
>  not get in the way of the compiler.
>
>  In summary, NaN seems indistinguishable to me from an ignorable error
>  indicator at the hardware level.  It is not conceptually a 'valid input'
>  to any of these functions, but is a clever design to propagate the error
>  properly when ignored.  Conceptually, it seems no different from
>  'ignore-errors in common-lisp.  So really the spec is not all that far
>  away from IEEE.
>
> I suppose that that is true, but I don't think any Lisp programmer
> would wrap their entire programs in a ignore-errors form.  That's
> usually one done on a very limited scope.  Having traps off to get
> NaN, is basically the same idea.
>

Wrapping code in ignore-errors is totally unnecessary.  I can insert a
specific handler within GCL's type-error mechanism to skip the error
when testing NaN depending on a global variable setting.  One question
is whether such a setting governing skipping a lisp error should be the
same as or distinct from the setting enabling hardware traps.

>  As for common-lisp types, the obvious path is what GCL and others
>  currently implement, double precision NaN is of type 'long-float and
>  hence 'number.  This actually means that lisp will *stray* from IEEE and
>
> I think one thing that confuses me, is that for gcl, single-float =
> double-float = double precision.  short-float is single precision.  I
> think long-float is double-precision.  I think all other lisps have
> single-float = single precision, double-float = double precision.
> Short-float is usually the same as single-float.  Long-float is
> usually double-float, if they don't have a separate long-float (like
> clisp).
>
> So whenever you say long-float, I sometimes think of actual
> long-floats like clisp, but you're actually talking about
> double-precision floats.

Thanks, this needs to be cleaned up.  I think single-float should be
short-float (e.g. 4 bytes).

I suppose in principle each of these could be distinct, long-float could
be long double, supported on most machines, and short float could be a
new 16bit float :-).  It looks like the next GCL version will be able to
pass 4 unboxed arguments of the same size on 64bit machines, 'object'
(e.g. void *), unsigned long, double, and float complex.  I have space
in the argument descriptor for 4 such formats, but on 32bit machines, we
only have three useful ones, given the absence of 'short float complex'.

Take care,
-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah