From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.user Subject: Re: Can somebody help to explain why result from atan does not equal a real? Date: Thu, 31 Jan 2013 08:32:53 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c816cf50d4804d495a994 X-Trace: ger.gmane.org 1359639183 22733 80.91.229.3 (31 Jan 2013 13:33:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jan 2013 13:33:03 +0000 (UTC) Cc: Guile Mailing List To: Hengqing Hu Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Jan 31 14:33:23 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U0uGZ-0000fR-3y for guile-user@m.gmane.org; Thu, 31 Jan 2013 14:33:23 +0100 Original-Received: from localhost ([::1]:47403 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0uGH-0006pI-1W for guile-user@m.gmane.org; Thu, 31 Jan 2013 08:33:05 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0uG7-0006pB-E3 for guile-user@gnu.org; Thu, 31 Jan 2013 08:33:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U0uG6-0007xV-3c for guile-user@gnu.org; Thu, 31 Jan 2013 08:32:55 -0500 Original-Received: from mail-vc0-f179.google.com ([209.85.220.179]:51501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U0uG5-0007xI-VT for guile-user@gnu.org; Thu, 31 Jan 2013 08:32:54 -0500 Original-Received: by mail-vc0-f179.google.com with SMTP id gb23so1725999vcb.38 for ; Thu, 31 Jan 2013 05:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fCx4lUGhKtxVHJwimzCeVA41IicGCwWJy7IZLCj0S1Q=; b=utTAGsnpG85rrsErkG/kgwOmi784trn+HYnu5mVzOdnegyQCfYCJDIZlOFe4IsKHgl aS1agDei2vZOKLJeUYrliGfIuA5UxZ76Wsnh3sqf1MZrZonZwhv5CVogiM9ZErPKOgje IAzemISqGVBudukG9O1a5vf0bKoWPx4/QaEMPSRdwZALYVbMoTBqSDomhX5QWODOuoL1 ZOJQqjybrnVKWr+fyEYEhCdx/1rZX6mjnt+nNDU0A4/bZosCKOTuAzO61ibYU0VkUELz A6lVxYgAgYA3lBPf6bglQb3p13mkG/Zl32RcBnAxcj1lCus6n/xtajoiteZip7moBCqa Invw== X-Received: by 10.220.149.198 with SMTP id u6mr7876151vcv.52.1359639173467; Thu, 31 Jan 2013 05:32:53 -0800 (PST) Original-Received: by 10.58.171.41 with HTTP; Thu, 31 Jan 2013 05:32:53 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: ksjTEpOCIAp7NVsu1Luu1dzMU6k X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.179 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:9953 Archived-At: --f46d043c816cf50d4804d495a994 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --f46d043c816cf50d4804d495a994 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What you have here is a precision problem.

<= div style>When a floating-point number like pi is printed, I don't thin= k 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 t= hings 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= =3D 3.14159265358979
scheme@(guile-user)> (=3D 3.141592= 65358979 (atan 0 -1))
$8 = =3D #f
scheme@(guile-user= )> (=3D $7 (atan 0 -1))
$9 =3D #t

It might be possible to have Guile print more digits and mak= e 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> (=3D 3.14159265358979 3.14159265358979)
#t
guile> (=3D (atan 0 -1) 3.14159265358979)
#f

--
Best Regards, Hengqing Hu


--f46d043c816cf50d4804d495a994--