What you have here is a precision problem.

When a floating-point number like pi is printed, I don't think you can guarantee that the string representation will be read in the same way it was read out. So when guile reads "3.14159265358979", it gives you some floating point number that is *close to* what (atan 0 -1) returns, but not necessarily the same.

That's why line 2 in your example returned #t - because both things were read as the same number - but #f for line 3 - because (atan 0 -1) returns something slightly different. You can see this in Guile 2.0:

scheme@(guile-user)> (atan 0 -1)
$7 = 3.14159265358979
scheme@(guile-user)> (= 3.14159265358979 (atan 0 -1))
$8 = #f
scheme@(guile-user)> (= $7 (atan 0 -1))
$9 = #t

It might be possible to have Guile print more digits and make this problem go away.

Noah Lavine


On Thu, Jan 31, 2013 at 5:50 AM, Hengqing Hu <hengqing.hu@gmail.com> wrote:
Dear list,

The following behavior is observed on both guile 1.8 and guile 2.0.
Is it correct?
Can somebody elaborate why it happens?

guile> (atan 0 -1)
3.14159265358979
guile> (= 3.14159265358979 3.14159265358979)
#t
guile> (= (atan 0 -1) 3.14159265358979)
#f

--
Best Regards, Hengqing Hu