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
>
>