[cmucl-imp] [cmucl-help] NaN

[Nikodemus Siivola]

Also note that this in the REPL. Compiler and evaluator (and code compiled
in different optimization policies!) may well behave differently -- either
intentionally, or because floating point is hard and bugs slip through.

Cheers,

 -- nikodemus


On Fri, Jan 13, 2017 at 2:10 AM, Raymond Toy <toy.raymond at gmail.com> wrote:

> >>>>> "Marco" == Marco Antoniotti <marcoxa at cs.nyu.edu> writes:
>
>     Marco> However, as usual, the situation is messier that one knew.
>
>     Marco> Consider this.
>
>     Marco> CMUCL (and SBCL)
>
>     CL-USER> (/ 0.0 0.0)
>     Marco> ; Evaluation aborted on #<FLOATING-POINT-INVALID-OPERATION
> {48A20E2D}>.
>
>
>     Marco> LW
>
>     Marco> CL-USER 17 > (/ 0.0 0.0)
>     Marco> Error: Division-by-zero caused by / of (0.0 0.0).
>
>
>     Marco> Allegro
>
>     Marco> CG-USER(1): (/ 0.0 0.0)
>     Marco> Error: Division-by-zero
>
>
>     Marco> CCL
>
>     Marco> ? (/ 0.0 0.0)
>     >> Error: FLOATING-POINT-INVALID-OPERATION detected
>     >> performing / on (0.0 0.0)
>
>
>     Marco> ABCL
>
>     Marco> CL-USER(1): (/ 0.0 0.0)
>     Marco> #<SINGLE-FLOAT NaN>
>
>
>     Marco> So.  According to my understanding, the behavior of
>     Marco> CMUCL/SBCL and CCL is “correct”.  The same could be said
>     Marco> for ABCL.  LW and Allegro instead signal the wrong
>     Marco> exception.
>
>     Marco> What do you think?
>
> I had to look this up.  The IEEE754 spec says 0/0 is an invalid
> operation (sec 7.2, item d). So ccl, cmucl, and sbcl are ok.  abcl is
> ok if exceptions are disabled.  I'm guessing LW and Allegro are
> checking manually for division by 0 instead of just letting the
> machine do the division and signaling there.  The nice thing about LW
> and Allegro is that you don't have to go through a signal handler for
> this.
>
> --
> Ray
>
>
>
>
>
> _______________________________________________
> cmucl-imp mailing list
> cmucl-imp at lists.zs64.net
> https://lists.zs64.net/mailman/listinfo/cmucl-imp
>