From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#30953: =?UTF-8?Q?=E2=80=98min=E2=80=99?= and =?UTF-8?Q?=E2=80=98max=E2=80=99?= behavior when mixing exact and inexact numbers. Date: Mon, 26 Mar 2018 22:21:25 -0400 Message-ID: <87bmfa45sq.fsf@netris.org> References: <87sh8nkjuy.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522117295 11255 195.159.176.226 (27 Mar 2018 02:21:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 02:21:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cc: 30953@debbugs.gnu.org To: Mathieu Lirzin Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Mar 27 04:21:31 2018 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0eEr-0002qg-Q2 for guile-bugs@m.gmane.org; Tue, 27 Mar 2018 04:21:29 +0200 Original-Received: from localhost ([::1]:59990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0eGv-0001NW-BH for guile-bugs@m.gmane.org; Mon, 26 Mar 2018 22:23:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0eGQ-00017e-Fz for bug-guile@gnu.org; Mon, 26 Mar 2018 22:23:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0eGM-0004DZ-EM for bug-guile@gnu.org; Mon, 26 Mar 2018 22:23:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47087) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f0eGM-0004DK-Au for bug-guile@gnu.org; Mon, 26 Mar 2018 22:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f0eGM-0008DN-2U for bug-guile@gnu.org; Mon, 26 Mar 2018 22:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 27 Mar 2018 02:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30953 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 30953-submit@debbugs.gnu.org id=B30953.152211734431529 (code B ref 30953); Tue, 27 Mar 2018 02:23:02 +0000 Original-Received: (at 30953) by debbugs.gnu.org; 27 Mar 2018 02:22:24 +0000 Original-Received: from localhost ([127.0.0.1]:54984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0eFk-0008CR-Hf for submit@debbugs.gnu.org; Mon, 26 Mar 2018 22:22:24 -0400 Original-Received: from world.peace.net ([50.252.239.5]:57062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0eFi-0008C3-LP; Mon, 26 Mar 2018 22:22:22 -0400 Original-Received: from pool-72-93-33-63.bstnma.east.verizon.net ([72.93.33.63] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1f0eFc-000363-Du; Mon, 26 Mar 2018 22:22:16 -0400 In-Reply-To: <87sh8nkjuy.fsf@gnu.org> (Mathieu Lirzin's message of "Mon, 26 Mar 2018 16:11:01 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.lisp.guile.bugs:9037 Archived-At: tags 30953 + notabug close 30953 thanks Hi Mathieu, Mathieu Lirzin writes: > I am observing a unexpected behavior of =E2=80=98min=E2=80=99 and =E2=80= =98max=E2=80=99: > > --8<---------------cut here---------------start------------->8--- > scheme@(guile-user)> (min 1 2.4) > $2 =3D 1.0 > scheme@(guile-user)> (min 1/2 4.0) > $7 =3D 0.5 > scheme@(guile-user)> (max 4 3.5) > $4 =3D 4.0 > --8<---------------cut here---------------end--------------->8--- > > I would expect the results to be integers instead. 1.0 and 4.0 _are_ integers, in the terminology of both Scheme and mathematics. However, they are _inexact_ integers. I'm not sure why you would expect (min 1/2 4.0) to return an integer. By the result of exactness propagation in Scheme, these results must be inexact, because the results depend on the value of an inexact argument. For example, in (min 1 2.4), if the 2.4 were replaced with 0.8, then the result would be 0.8 instead of 1.0. It's entirely possible that the inexact arithmetic leading to 2.4 might have a maximum error greater than 1.4. The idea is that if Scheme tells you that the result of some computation is exact, then it could in principle be proved to be the true mathematical result, and therefore known to be unaffected by any inexact computation. So, (min 1 2.4) could only return an exact 1 if it were somehow known that the 2.4 has a maximum error of 1.4. I suspect you are thinking to yourself "the 2.4 might be imprecise, but surely it's not so far off to affect the result here." However, there's no upper bound on the error of an inexact number, when one considers the entire history of inexact operations that led to it. For details, see R5RS section 6.2.2 (Exactness), R6RS section 11.7.1 (Propagation of exactness and inexactness), and R7RS section 6.2.2 (Exactness). > AIUI the > implementation of the =E2=80=98min=E2=80=99 procedure should to be equiva= lent to: > > (define (min val . rest) > (let loop ((x val) (other rest)) > (match other > (() x) > ((y . rest) (loop (if (< x y) x y) rest))))) This would violate the exactness propagation rules. > Maybe there is a good performance reason for the current behavior. If > that's the case then it should be specified in the manual that exact > numbers are converted to real numbers when at least one of the arguments > is inexact. In Scheme (and mathematics), 1 and 1/2 are considered real numbers, and 1.0 is both a real number and an integer. In Scheme, the only difference between 1 and 1.0 is that 1 is exact and 1.0 is inexact. Lesser programming languages say that 1 is not a real number and that 1.0 is not an integer, but from a mathematical point of view, that's nonsense :) Regards, Mark