Greetings! Raymond Toy <toy.raym...@gmail.com> writes:
> On Mon, Feb 26, 2024 at 5:28 AM Camm Maguire <c...@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 c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
