From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#13905: (max inexact exact) => always inexact? Date: Fri, 08 Mar 2013 13:44:54 -0500 Message-ID: <87boat689l.fsf@tines.lan> References: <75E5F130-E4B6-49CF-9937-CF2D153B494C@bluewin.ch> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1362768342 17172 80.91.229.3 (8 Mar 2013 18:45:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 18:45:42 +0000 (UTC) Cc: 13905@debbugs.gnu.org To: Daniel Llorens Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Mar 08 19:46:02 2013 Return-path: Envelope-to: guile-bugs@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 1UE2Ir-00086L-Eq for guile-bugs@m.gmane.org; Fri, 08 Mar 2013 19:46:01 +0100 Original-Received: from localhost ([::1]:57298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2IV-00062t-LC for guile-bugs@m.gmane.org; Fri, 08 Mar 2013 13:45:39 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2IN-00062j-2z for bug-guile@gnu.org; Fri, 08 Mar 2013 13:45:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE2IF-0004fi-M2 for bug-guile@gnu.org; Fri, 08 Mar 2013 13:45:31 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2IF-0004fa-Ha for bug-guile@gnu.org; Fri, 08 Mar 2013 13:45:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UE2Ir-0006Og-Ml for bug-guile@gnu.org; Fri, 08 Mar 2013 13:46:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 08 Mar 2013 18:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13905 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 13905-submit@debbugs.gnu.org id=B13905.136276835424576 (code B ref 13905); Fri, 08 Mar 2013 18:46:01 +0000 Original-Received: (at 13905) by debbugs.gnu.org; 8 Mar 2013 18:45:54 +0000 Original-Received: from localhost ([127.0.0.1]:39866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2Ij-0006OL-MU for submit@debbugs.gnu.org; Fri, 08 Mar 2013 13:45:54 -0500 Original-Received: from world.peace.net ([96.39.62.75]:53369 ident=hope6) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2Ig-0006OB-6Q for 13905@debbugs.gnu.org; Fri, 08 Mar 2013 13:45:51 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UE2Hu-0007bN-W9; Fri, 08 Mar 2013 13:45:03 -0500 In-Reply-To: <75E5F130-E4B6-49CF-9937-CF2D153B494C@bluewin.ch> (Daniel Llorens's message of "Fri, 8 Mar 2013 13:43:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6884 Archived-At: tags 13905 notabug close 13905 thanks Daniel Llorens writes: > Not necessarily a bug, but I'd like to hear some thoughts on this. > > In current Guile > > (max -inf.0 9) =3D> 9.0 Yes, and this is correct. In general, the error of an inexact number is unbounded. Consider the inexact infinities (which really just mean some number larger than the largest representable inexact number). An inexact infinity might be the result of taking the reciprocal of an inexact number (let's call it 'X') that's very close to zero. If 'X' was slightly different, (/ X) might be anywhere from -inf.0 to +inf.0 or anywhere in between. A proper Scheme system must not produce an exact result unless that result is *provably* the right answer, without any error whatsoever. In the case of (max -inf.0 9), we cannot say for sure that 9 is the right answer, because the true value of the first argument could be anything. > The manual says > >> R5RS requires that, with few exceptions, a calculation involving >> inexact numbers always produces an inexact result [...] The only >> exception to the above requirement is when the values of the inexact >> numbers do not affect the result. For example (expt n 0) is =E2=80=981= =E2=80=99 for >> any value of n, therefore (expt 5.0 0) is permitted to return an >> exact =E2=80=981=E2=80=99. > > In fact, in current Guile > > (expt 5.0 0) =3D> 1 Right. That's because (expt X N) for exact non-negative integer N is equivalent to (* X ...) with N multiples of X. Therefore (expt X 0) is equivalent to (*), so the imprecision of X does not affect the result. > (* -1.0 0) =3D> 0.0 Yes, I did this deliberately, because (* +inf.0 0) =3D> +nan.0. However, I've since come to believe that (* X 0) should be 0 for *any* X, even if X is an infinity or NaN. I should probably change this at some point. > R5RS says specifically for max / min > >> If any argument is inexact, then the result will also be inexact >> (unless the procedure can prove that the inaccuracy is not large >> enough to affect the result, which is possible only in unusual >> implementations). > > Certainly, there are calculations that return -inf.0 when done with > inexact arithmetic that would have returned {hugely negative exact > number} if done with exact arithmetic. There are also calculations that return -inf.0 that would have returned {hugely POSITIVE exact number} if done with exact arithmetic. That's precisely the reason why the result of (max -inf.0 9) must be inexact. > My interest in this is that I don't want > > (fold max -inf.0 exact-number-list) > > to return an inexact number. I also find inconvenient that max doesn't > return one of its arguments even though there's no NaN involved. I understand that it would be convenient to avoid handling the empty list specially in your example above, and I sympathize. However, it is far more important to never produce an exact result unless we can prove that it is precisely equal to the result we would have gotten if exact arithmetic was used everywhere. This principle allows the construction of provably correct programs involving arithmetic. Thanks, Mark