Re: [cmucl-imp] [cmucl-help] NaN
Thank you James, thank you Stelian. The CFFI solution seems very interesting and the codec James pointed me to are also useful. Do you have any ideas about how your code(s) would impact the lower levels of the implementation? Meaning: the solutions both of you propose essentially use the FFI: any ideas about how such solutions would impact memory management? Just curious. All the best Marco
On Jan 11, 2017, at 24:25 , james anderson <james@dydra.com> wrote:
good evening;
On 2017-01-11, at 00:17, Raymond Toy <toy.raymond@gmail.com> wrote:
[…] You will have to figure out how to get LW or your favorite impl to do something similar.
that is what the code i pointed you at does.
best regards, from berlin,
-- Marco Antoniotti
good morning;
On 2017-01-11, at 09:48, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Thank you James, thank you Stelian.
The CFFI solution seems very interesting and the codec James pointed me to are also useful.
i sent marco an off-line note, in which i had pointed out some code which figures (among other things) in an amqp implementation, where it is figures in buffer codecs. for the curious, it is to be found here: https://github.com/lisp/de.setf.utility/tree/master/codecs/float-codecs.lisp my memory may be spotty, but i do not recall that it relied on cffi. the consequence is much the same, in that it arranges the bist in memory, but the mechanism is different. best regards, from berlin,
Do you have any ideas about how your code(s) would impact the lower levels of the implementation? Meaning: the solutions both of you propose essentially use the FFI: any ideas about how such solutions would impact memory management?
you have lost me here. each of them arranges to write/read a memory word. the codec version targets an unboxed byte array while the cffi gets a pointer to an arbitrary word. (at least, that is how i read it.) you might be more successful getting the later onto the stack via a dynamic extent declaration. some lisps let force arrays to the stack, others do not. is that what you meant? best regards, from berlin,
Just curious.
All the best
Marco
On Jan 11, 2017, at 24:25 , james anderson <james@dydra.com> wrote:
good evening;
On 2017-01-11, at 00:17, Raymond Toy <toy.raymond@gmail.com> wrote:
[…] You will have to figure out how to get LW or your favorite impl to do something similar.
that is what the code i pointed you at does.
best regards, from berlin,
-- Marco Antoniotti
_______________________________________________ cmucl-imp mailing list cmucl-imp@lists.zs64.net https://lists.zs64.net/mailman/listinfo/cmucl-imp
"james" == james anderson <james.anderson@setf.de> writes:
james> good morning; >> On 2017-01-11, at 09:48, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote: >> >> Thank you James, thank you Stelian. >> >> The CFFI solution seems very interesting and the codec James pointed me to are also useful. james> i sent marco an off-line note, in which i had pointed out some code which figures (among other things) in an amqp implementation, where it is figures in buffer codecs. james> for the curious, it is to be found here: james> https://github.com/lisp/de.setf.utility/tree/master/codecs/float-codecs.lisp This is also pretty nice and mostly portable. I think with a bit of work it can be made (almost) completely portable using just CL functions. I guess the main problem is constructing infinities. Testing for NaN is pretty easy: (= x x) is always false if x is NaN. -- Ray
On Jan 11, 2017, at 17:14 , Raymond Toy <toy.raymond@gmail.com> wrote:
"james" == james anderson <james.anderson@setf.de> writes:
james> good morning;
On 2017-01-11, at 09:48, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Thank you James, thank you Stelian.
The CFFI solution seems very interesting and the codec James pointed me to are also useful.
james> i sent marco an off-line note, in which i had pointed out some code which figures (among other things) in an amqp implementation, where it is figures in buffer codecs. james> for the curious, it is to be found here:
james> https://github.com/lisp/de.setf.utility/tree/master/codecs/float-codecs.lisp
This is also pretty nice and mostly portable. I think with a bit of work it can be made (almost) completely portable using just CL functions. I guess the main problem is constructing infinities. Testing for NaN is pretty easy: (= x x) is always false if x is NaN.
Do you have an idea about how to go ahead and construct infinities? MA -- Marco Antoniotti
"Marco" == Marco Antoniotti <marcoxa@cs.nyu.edu> writes:
>> On Jan 11, 2017, at 17:14 , Raymond Toy <toy.raymond@gmail.com> wrote: >> >>>>>>> "james" == james anderson <james.anderson@setf.de> writes: >> james> good morning; >>>> On 2017-01-11, at 09:48, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote: >>>> >>>> Thank you James, thank you Stelian. >>>> >>>> The CFFI solution seems very interesting and the codec James pointed me to are also useful. >> james> i sent marco an off-line note, in which i had pointed out some code which figures (among other things) in an amqp implementation, where it is figures in buffer codecs. james> for the curious, it is to be found here: >> james> https://github.com/lisp/de.setf.utility/tree/master/codecs/float-codecs.lisp >> >> This is also pretty nice and mostly portable. I think with a bit of >> work it can be made (almost) completely portable using just CL >> functions. I guess the main problem is constructing infinities. >> Testing for NaN is pretty easy: (= x x) is always false if x is NaN. Marco> Do you have an idea about how to go ahead and construct infinities? In pure CL? No, I don't know of any way to do that. Besides, support for infinities isn't required. I don't think clisp can handle infinities (or NaNs?). At best, the CL implementation has a way to do it, or you can use cffi. -- Ray
On Jan 12, 2017, at 16:47 , Raymond Toy <toy.raymond@gmail.com> wrote:
"Marco" == Marco Antoniotti <marcoxa@cs.nyu.edu> writes:
On Jan 11, 2017, at 17:14 , Raymond Toy <toy.raymond@gmail.com> wrote:
>> "james" == james anderson <james.anderson@setf.de> writes:
james> good morning;
On 2017-01-11, at 09:48, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Thank you James, thank you Stelian.
The CFFI solution seems very interesting and the codec James pointed me to are also useful.
james> i sent marco an off-line note, in which i had pointed out some code which figures (among other things) in an amqp implementation, where it is figures in buffer codecs. james> for the curious, it is to be found here:
james> https://github.com/lisp/de.setf.utility/tree/master/codecs/float-codecs.lisp
This is also pretty nice and mostly portable. I think with a bit of work it can be made (almost) completely portable using just CL functions. I guess the main problem is constructing infinities. Testing for NaN is pretty easy: (= x x) is always false if x is NaN.
Marco> Do you have an idea about how to go ahead and construct infinities?
In pure CL? No, I don't know of any way to do that. Besides, support for infinities isn't required. I don't think clisp can handle infinities (or NaNs?).
At best, the CL implementation has a way to do it, or you can use cffi.
Yes. I understand. However, as usual, the situation is messier that one knew. Consider this. CMUCL (and SBCL) CL-USER> (/ 0.0 0.0) ; Evaluation aborted on #<FLOATING-POINT-INVALID-OPERATION {48A20E2D}>. LW CL-USER 17 > (/ 0.0 0.0) Error: Division-by-zero caused by / of (0.0 0.0). Allegro CG-USER(1): (/ 0.0 0.0) Error: Division-by-zero CCL ? (/ 0.0 0.0)
Error: FLOATING-POINT-INVALID-OPERATION detected performing / on (0.0 0.0)
ABCL CL-USER(1): (/ 0.0 0.0) #<SINGLE-FLOAT NaN> So. According to my understanding, the behavior of CMUCL/SBCL and CCL is “correct”. The same could be said for ABCL. LW and Allegro instead signal the wrong exception. What do you think? MA -- Marco Antoniotti
"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
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
participants (4)
-
james anderson -
Marco Antoniotti -
Nikodemus Siivola -
Raymond Toy