From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 26 10:11:27 2018 Received: (at submit) by debbugs.gnu.org; 26 Mar 2018 14:11:27 +0000 Received: from localhost ([127.0.0.1]:54467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0SqN-0007no-GY for submit@debbugs.gnu.org; Mon, 26 Mar 2018 10:11:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0SqL-0007nZ-2R for submit@debbugs.gnu.org; Mon, 26 Mar 2018 10:11:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0SqC-0002NA-1k for submit@debbugs.gnu.org; Mon, 26 Mar 2018 10:11:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45289) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f0SqB-0002N0-Mb for submit@debbugs.gnu.org; Mon, 26 Mar 2018 10:11:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Sq5-0001Ja-WC for bug-guile@gnu.org; Mon, 26 Mar 2018 10:11:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0Sq0-0002G5-2Z for bug-guile@gnu.org; Mon, 26 Mar 2018 10:11:09 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0Spz-0002G0-VV for bug-guile@gnu.org; Mon, 26 Mar 2018 10:11:04 -0400 Received: from [2a01:e35:2ec2:e580:7d5f:f616:fc6f:3970] (port=35610 helo=godel) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f0Spz-0006lD-GR for bug-guile@gnu.org; Mon, 26 Mar 2018 10:11:03 -0400 From: Mathieu Lirzin To: bug-guile@gnu.org Subject: =?utf-8?B?4oCYbWlu4oCZ?= and =?utf-8?B?4oCYbWF44oCZ?= behavior when mixing exact and inexact numbers. Date: Mon, 26 Mar 2018 16:11:01 +0200 Message-ID: <87sh8nkjuy.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hello, I am observing a unexpected behavior of =E2=80=98min=E2=80=99 and =E2=80=98= max=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. AIUI the implementation of the =E2=80=98min=E2=80=99 procedure should to be equivale= nt to: (define (min val . rest) (let loop ((x val) (other rest)) (match other (() x) ((y . rest) (loop (if (< x y) x y) rest))))) 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. Thanks. --=20 Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 26 22:22:24 2018 Received: (at 30953) by debbugs.gnu.org; 27 Mar 2018 02:22:24 +0000 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 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 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 From: Mark H Weaver To: Mathieu Lirzin Subject: Re: bug#30953: =?utf-8?B?4oCYbWlu4oCZ?= and =?utf-8?B?4oCYbWF4?= =?utf-8?B?4oCZ?= behavior when mixing exact and inexact numbers. References: <87sh8nkjuy.fsf@gnu.org> Date: Mon, 26 Mar 2018 22:21:25 -0400 In-Reply-To: <87sh8nkjuy.fsf@gnu.org> (Mathieu Lirzin's message of "Mon, 26 Mar 2018 16:11:01 +0200") Message-ID: <87bmfa45sq.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 30953 Cc: 30953@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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 From unknown Tue Sep 09 16:56:55 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 24 Apr 2018 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator