Can somebody help to explain why result from atan does not equal a real?

Can somebody help to explain why result from atan does not equal a real?

[Hengqing Hu]

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

Re: Can somebody help to explain why result from atan does not equal a real?

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2474 bytes --]

Re: Can somebody help to explain why result from atan does not equal a real?

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Thu, Jan 31, 2013 at 08:32:53AM -0500, Noah Lavine wrote:
     What you have here is a precision problem.
     
     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

pi is an irrational number.  You would need an infinite number of digits wouldn't you?

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Can somebody help to explain why result from atan does not equal a real?

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

On Thu, Jan 31, 2013 at 9:50 AM, John Darrington <
john@darrington.wattle.id.au> wrote:
>
> pi is an irrational number.  You would need an infinite number of digits
> wouldn't you?
>


Good point :-). All I meant was enough digits that it parsed as the same
floating-point number that (atan 0 -1) returns.

Noah Lavine

[-- Attachment #2: Type: text/html, Size: 870 bytes --]

Re: Can somebody help to explain why result from atan does not equal a real?

[Mark H Weaver]

Hengqing Hu <hengqing.hu@gmail.com> writes:
> 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

Sorry, this is due to an inadequate 'number->string' implementation in
Guile.  A proper implementation should guarantee that when the string is
read back in, you'll get precisely the same number back, and recent
Scheme standards mandate this.  At present, Guile does not always print
enough digits to guarantee this.

I plan to soon rewrite Guile's 'number->string' based on "Printing
Floating-Point Numbers Quickly and Accurately" by Dybvig and Burger.
I recently started that work but became distracted by more pressing
matters.  I hope to get back to it soon.

    Regards,
      Mark

Re: Can somebody help to explain why result from atan does not equal a real?

[Mark H Weaver]

I wrote:
> Sorry, this is due to an inadequate 'number->string' implementation in
> Guile.

Having looked more closely, I see now that our 'string->number' is also
less precise than it should be.  I'll fix these issues soon.

    Mark

Re: Can somebody help to explain why result from atan does not equal a real?

[Mark H Weaver]

I wrote:
> Having looked more closely, I see now that our 'string->number' is also
> less precise than it should be.

Sorry, I was mistaken about this.  Our 'string->number' is fine.

     Mark