(log #c(0 1) #c(0 -1)) errors
With 21.2.1 I get:
(log #c(0 1) #c(0 -1))
Debugger received error of type: DIVISION-BY-ZERO #<a DIVISION-BY-ZERO 0x7f8925037640> Error flushed. gcl, sbcl and ccl all return #C(-1.0 0.0). other non-lisp software agrees. i haven't yet tried master. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
With 21.2.1 I get:
(log #c(0 1) #c(0 -1))
Debugger received error of type: DIVISION-BY-ZERO #<a DIVISION-BY-ZERO 0x7f8925037640>
I also noticed that setting: (si::trap-fpe t nil) changes the result to: (log #c(0 1) #c(0 -1)) #C(#<single-float quiet NaN> #<single-float quiet NaN>) Paul
"P" == PR <pls.153@protonmail.com> writes:
P> I also noticed that setting: P> (si::trap-fpe t nil) P> changes the result to: P> (log #c(0 1) #c(0 -1)) P> #C(#<single-float quiet NaN> #<single-float quiet NaN>) ah. interesting. thanks. i hadn't thought to test that. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
origin/develop as of commit 858687605134788f52b904fc2bc365462e2d6ac9 fails with the same error. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
On 3/21/23 07:20, James Cloos wrote:
With 21.2.1 I get:
(log #c(0 1) #c(0 -1)) Debugger received error of type: DIVISION-BY-ZERO #<a DIVISION-BY-ZERO 0x7f8925037640> Error flushed.
gcl, sbcl and ccl all return #C(-1.0 0.0).
Probably related. (log #c(0 1)) and (log #c(0 -1)) both signal a division by zero. The answer should be #c(0 1.5707964) and #c(0 -1.5707964), respectively.
making either of the coponents of the first #c() float avoids that bug but gets a different one: ===
(log #c(0e0 1) #c(0 -1))
#C(-0.0 -0.0)
(log #c(0 1e0) #c(0 -1))
#C(-0.0 -0.0) === but leaving the first #c() rational and making the second float does not avoid it. otoh, all float gets the correct results: ===
(log #c(0.0 1.0) #c(0.0 -1.0))
#C(-1.0 0.0)
(log #c(0l0 1l0) #c(0l0 -1l0))
#C(-1.0l0 0.0l0) === -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
Dear James, This has been fixed now in the develop branch of the git repository. Thanks for the report! Best regards, Marius Gerbershagen Am 22.03.23 um 16:54 schrieb James Cloos:
making either of the coponents of the first #c() float avoids that bug but gets a different one:
===
(log #c(0e0 1) #c(0 -1))
#C(-0.0 -0.0)
(log #c(0 1e0) #c(0 -1))
#C(-0.0 -0.0) ===
but leaving the first #c() rational and making the second float does not avoid it.
otoh, all float gets the correct results:
===
(log #c(0.0 1.0) #c(0.0 -1.0))
#C(-1.0 0.0)
(log #c(0l0 1l0) #c(0l0 -1l0))
#C(-1.0l0 0.0l0) ===
-JimC
participants (4)
-
James Cloos -
Marius Gerbershagen -
PR -
Raymond Toy