Re: +-Inf and NaN

Not sure about* most* users.  You can read my old article about IEEE 754
and programming languages.
At least the intent for NaNs was that they would propagate through a
computation and
emerge only if relevant. At least under some conditions.
I personally have no realistic use cases for using traps for numerics, or
for propagating NaNs,
but I'm not a professional error analyst; few if any Lisp programmers
are... (Ray?)
If all that is being questioned is the default enabling of trapping, it
doesn't seem much
of an issue.
  It would be nice to see if we can (say) fill an "uninitialized" float
array by
initializing it with NaNs, or use the mantissa of a NaN for storing info.
RJF

On Wed, Feb 28, 2024 at 5:44 AM Camm Maguire <[email protected]> wrote:

> Greetings!
>
> Raymond Toy <[email protected]> writes:
>
> > On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <[email protected]>
> 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                                        [email protected]
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss