Fwd: +-Inf and NaN

[Grégory Vanuxem]

Forwarded, it was intended to be sent here, sorry Camm. Not used to
the gnu.org mailing lists.

---------- Forwarded message ---------
De : Grégory Vanuxem <g.vanuxem@gmail.com>
Date: mer. 28 févr. 2024 à 19:38
Subject: Re: +-Inf and NaN
To: Camm Maguire <camm@maguirefamily.org>


hello,

I have been reading this interesting discussion and here is a simple
"my two cents" on throwing or not errors if NaNs and consort are
encountered. I use Julia in an embedded way with different CL
implementations, GCl-2.7 is on the road.

Julia has a mechanism at startup to handle or not signals,
"--handle-signals={yes*|no} Enable or disable Julia's default signal
handlers", this is very handy, particularly with SBCL where it needs
to handle bad memory access for example or the different floats traps.
In an embedded way I use (in C, I use a wrapper) :

    jl_options.handle_signals = JL_OPTIONS_HANDLE_SIGNALS_OFF;
    jl_init();

That way, float traps from Julia can easily be handled at CL level.
What about, for GCL, say, use the IEEE 754 scheme and propagate
silently NaNs, +-Inf etc. and do not interrupt the computation. Or
depending on a startup option signals the float traps and throws an
error for example, depending on the GCL signal handler?

Just my two cents,

Regards,

- Greg

Le mer. 21 févr. 2024 à 00:19, Camm Maguire <camm@maguirefamily.org> a écrit :
>
> Greetings!  I know this has been discussed before, but I would like to
> explore the possibility of defining these bit patterns as members of a
> special type orthogonal to common-lisp::number.  This is prompted by the
> NaN blockage on the compiler optimizing (= a a) (or equivalent bindings)
> to t, and indeed the common lisp spec appears to specify that eq implies
> =.  I think maxima tries to detect NaNs using (/= a a).
>
> We also have the following charming behavior:
>
> (typep nan 'long-float) ->t
> (typep nan '(long-float 0) ->nil
> (typep nan '(long-float * 0)) ->nil
> (typep nan '(or (long-float 0) (long-float * 0))) ->nil
>
> but the first and last types are of course identical.
>
> If NaN was truly 'not a number', the numerical functions would trigger
> an error on input only when compiled with safety, and might be arranged
> to do likewise on return, so the signatures would remain the same but
> the user could still access the values when compiling at (safety 0).
> Thoughts?
>
> Take care,
> --
> Camm Maguire                                        camm@maguirefamily.org
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>