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@gmail.com> wrote:
"Marco" == Marco Antoniotti <marcoxa@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@lists.zs64.net https://lists.zs64.net/mailman/listinfo/cmucl-imp