GNU logs - #30426, boring messages


Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: bil@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 11 Feb 2018 23:15:02 +0000
Resent-Message-ID: <handler.30426.B.151839085214605 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: 30426 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-guile@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.151839085214605
          (code B ref -1); Sun, 11 Feb 2018 23:15:02 +0000
Received: (at submit) by debbugs.gnu.org; 11 Feb 2018 23:14:12 +0000
Received: from localhost ([127.0.0.1]:38718 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1el0p2-0003nV-JM
	for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 18:14:12 -0500
Received: from eggs.gnu.org ([208.118.235.92]:40929)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bil@HIDDEN>) id 1el0ZA-0003Q0-4f
 for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 17:57:48 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bil@HIDDEN>) id 1el0Yw-0004rB-1K
 for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 17:57:42 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:38334)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <bil@HIDDEN>)
 id 1el0Yv-0004qU-Kd
 for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 17:57:33 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59524)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <bil@HIDDEN>) id 1el0Yf-0000RG-UA
 for bug-guile@HIDDEN; Sun, 11 Feb 2018 17:57:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <bil@HIDDEN>) id 1el0YN-0004Dx-Se
 for bug-guile@HIDDEN; Sun, 11 Feb 2018 17:57:17 -0500
Received: from mx0a-00000d04.pphosted.com ([148.163.149.245]:46786)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <bil@HIDDEN>)
 id 1el0YN-0004Aa-2h
 for bug-guile@HIDDEN; Sun, 11 Feb 2018 17:56:59 -0500
Received: from pps.filterd (m0102887.ppops.net [127.0.0.1])
 by mx0a-00000d04.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1BMrAEk010139
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:55 -0800
Received: from mx0a-00000d03.pphosted.com (mx0a-00000d03.pphosted.com
 [148.163.149.244])
 by mx0a-00000d04.pphosted.com with ESMTP id 2g2x0e8462-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:55 -0800
Received: from pps.filterd (m0102880.ppops.net [127.0.0.1])
 by mx0a-00000d03.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1BMtAIS005945
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:55 -0800
Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9])
 by mx0a-00000d03.pphosted.com with ESMTP id 2g20e1w28r-1
 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT)
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:55 -0800
Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1])
 by codegreen7.stanford.edu (Postfix) with ESMTP id 7E19547
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:45 -0800 (PST)
Received: from smtp.stanford.edu (smtp3.stanford.edu [171.67.219.83])
 by codegreen7.stanford.edu (Postfix) with ESMTP id 7194247
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:45 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtp.stanford.edu (Postfix) with ESMTPS id CC1981A00C3
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:54 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (authenticated bits=0)
 by cm-mail.stanford.edu (8.14.4/8.14.4) with ESMTP id w1BMusdl022558
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
 for <bug-guile@HIDDEN>; Sun, 11 Feb 2018 14:56:54 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 11 Feb 2018 14:56:54 -0800
From: bil@HIDDEN
Message-ID: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
X-Sender: bil@HIDDEN
User-Agent: Roundcube Webmail/1.0.12
x-proofpoint-stanford-dir: outbound
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-11_10:, , signatures=0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-11_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501
 malwarescore=0 suspectscore=1 phishscore=5 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=528 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1711220000 definitions=main-1802110302
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]
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-Mailman-Approved-At: Sun, 11 Feb 2018 18:14:11 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

A possible inconsistency:

scheme@(guile-user)> (version)
$1 = "2.0.13"

scheme@(guile-user)> (/ 1 (* 0 +nan.0))
$2 = +nan.0
scheme@(guile-user)> (/ 1 0 +nan.0)
<unnamed port>:3:0: In procedure #<procedure 5557c36be9c0 at <current 
input>:3:0 ()>:
<unnamed port>:3:0: Throw to key `numerical-overflow' with args `("/" 
"Numerical overflow" #f #f)
scheme@(guile-user)> (/ 1 +nan.0 0)
<unnamed port>:5:0: In procedure #<procedure 55ff47f4ad00 at <current 
input>:5:0 ()>:
<unnamed port>:5:0: Throw to key `numerical-overflow' with args `("/" 
"Numerical overflow" #f #f)

scheme@(guile-user)> (* +nan.0 0)
$1 = +nan.0
scheme@(guile-user)> (/ 1 +nan.0)
$2 = +nan.0

similarly with +inf.0:

scheme@(guile-user)> (/ 1 (* +inf.0 0))
$3 = +nan.0
scheme@(guile-user)> (/ 1 +inf.0 0)
<unnamed port>:6:0: In procedure #<procedure 5557c36f7740 at <current 
input>:6:0 ()>:
<unnamed port>:6:0: Throw to key `numerical-overflow' with args `("/" 
"Numerical overflow" #f #f)






Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: bil@HIDDEN
Subject: bug#30426: Acknowledgement (division inconsistency?)
Message-ID: <handler.30426.B.151839085214605.ack <at> debbugs.gnu.org>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
X-Gnu-PR-Message: ack 30426
X-Gnu-PR-Package: guile
Reply-To: 30426 <at> debbugs.gnu.org
Date: Sun, 11 Feb 2018 23:15:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 30426 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
30426: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D30426
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 Feb 2018 21:03:02 +0000
Resent-Message-ID: <handler.30426.B30426.15184693412459 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: bil@HIDDEN
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.15184693412459
          (code B ref 30426); Mon, 12 Feb 2018 21:03:02 +0000
Received: (at 30426) by debbugs.gnu.org; 12 Feb 2018 21:02:21 +0000
Received: from localhost ([127.0.0.1]:40098 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1elLEy-0000db-Qx
	for submit <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:02:21 -0500
Received: from world.peace.net ([50.252.239.5]:49992)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1elLEw-0000dN-P2
 for 30426 <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:02:19 -0500
Received: from pool-72-93-28-59.bstnma.east.verizon.net ([72.93.28.59]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1elLEq-0004c1-9I; Mon, 12 Feb 2018 16:02:12 -0500
From: Mark H Weaver <mhw@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
Date: Mon, 12 Feb 2018 16:01:39 -0500
In-Reply-To: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 (bil@HIDDEN's message of "Sun, 11 Feb 2018 14:56:54
 -0800")
Message-ID: <874lmlrkgc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Hi,

bil@HIDDEN writes:

> scheme@(guile-user)> (help '/)
> - Scheme Procedure: / [x [y .  rest]]
>      Divide the first argument by the product of the remaining
>      arguments.  If called with one argument Z1, 1/Z1 is returned.

This help text is indeed incorrect.  In fact, (/ x y z) is evaluated as
(/ (/ x y) z), which is not necessarily the same as (/ x (* y z)) when
using inexact arithmetic.

> A possible inconsistency:
>
> scheme@(guile-user)> (version)
> $1 = "2.0.13"
>
> scheme@(guile-user)> (/ 1 (* 0 +nan.0))
> $2 = +nan.0

Many years ago, I concluded that (* 0 +nan.0) and (* 0 +inf.0) should be
+nan.0, and that's what Guile does.  I now believe that (* 0 <anything>)
should be 0.  Both of these behaviors are allowed by the R6RS.  Note
that when I write '0', I mean an _exact_ zero.  So, the above expression
may raise an exception in a future version of Guile.

> scheme@(guile-user)> (/ 1 0 +nan.0)
> <unnamed port>:3:0: In procedure #<procedure 5557c36be9c0 at <current
> input>:3:0 ()>:
> <unnamed port>:3:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

The R6RS specifies that if all arguments to '/' are exact, then the
divisors must all be nonzero.  That does not apply to the above '/' call
because of the inexact +nan.0 argument.  However, our compiler
transforms (/ x y z) to (/ (/ x y) z) in an early pass.

> scheme@(guile-user)> (/ 1 +nan.0 0)
> <unnamed port>:5:0: In procedure #<procedure 55ff47f4ad00 at <current
> input>:5:0 ()>:
> <unnamed port>:5:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

This should probably return +nan.0, and that's what happens in Guile 2.2
for compiled code.  For some of these edge cases, our compiler has
different behavior than our core numeric procedures.

Our core '/' operator, as defined in numbers.c, raises an exception for
(/ x 0), for any 'x'.  This does not conform to the R6RS, which
specifies that (/ 0.0 0) => +inf.0.  I don't think that rule makes sense
because the sign of the result cannot be justified.  (/ 1 0.0) => +inf.0
and (/ 1 -0.0) => -inf.0 are more justifiable because of the signed
inexact zeroes, but an exact zero is not signed.

However, it may be that we should change this to conform to the R6RS,
and certainly it would be good for our compiler and interpreter to agree
on all of these edge cases.

> scheme@(guile-user)> (* +nan.0 0)
> $1 = +nan.0
> scheme@(guile-user)> (/ 1 +nan.0)
> $2 = +nan.0
>
> similarly with +inf.0:
>
> scheme@(guile-user)> (/ 1 (* +inf.0 0))
> $3 = +nan.0

If we change Guile so that (* 0 x) => 0 for all x, then the expression
above will raise an exception in a future version of Guile.

> scheme@(guile-user)> (/ 1 +inf.0 0)
> <unnamed port>:6:0: In procedure #<procedure 5557c36f7740 at <current
> input>:6:0 ()>:
> <unnamed port>:6:0: Throw to key `numerical-overflow' with args `("/"
> "Numerical overflow" #f #f)

As with the (/ 1 +nan.0 0) case above, this should probably return
+nan.0, and that's what happens in Guile 2.2 for compiled code.

What do you think?

    Regards,
      Mark




Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 Feb 2018 21:17:01 +0000
Resent-Message-ID: <handler.30426.B30426.15184701913694 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: bil@HIDDEN
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.15184701913694
          (code B ref 30426); Mon, 12 Feb 2018 21:17:01 +0000
Received: (at 30426) by debbugs.gnu.org; 12 Feb 2018 21:16:31 +0000
Received: from localhost ([127.0.0.1]:40111 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1elLSh-0000xV-FE
	for submit <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:16:31 -0500
Received: from world.peace.net ([50.252.239.5]:50022)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1elLSf-0000xI-LZ
 for 30426 <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:16:29 -0500
Received: from pool-72-93-28-59.bstnma.east.verizon.net ([72.93.28.59]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1elLSa-0004jv-1Q; Mon, 12 Feb 2018 16:16:24 -0500
From: Mark H Weaver <mhw@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 <874lmlrkgc.fsf@HIDDEN>
Date: Mon, 12 Feb 2018 16:15:51 -0500
In-Reply-To: <874lmlrkgc.fsf@HIDDEN> (Mark H. Weaver's message of "Mon, 12
 Feb 2018 16:01:39 -0500")
Message-ID: <87sha5q588.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Mark H Weaver <mhw@HIDDEN> writes:

> Our core '/' operator, as defined in numbers.c, raises an exception for
> (/ x 0), for any 'x'.  This does not conform to the R6RS, which
> specifies that (/ 0.0 0) => +inf.0.  I don't think that rule makes sense

Sorry, I meant to write (/ 1.0 0) => +inf.0, which is one of the
examples given in the R6RS.

> because the sign of the result cannot be justified.  (/ 1 0.0) => +inf.0
> and (/ 1 -0.0) => -inf.0 are more justifiable because of the signed
> inexact zeroes, but an exact zero is not signed.
>
> However, it may be that we should change this to conform to the R6RS,
> and certainly it would be good for our compiler and interpreter to agree
> on all of these edge cases.

        Mark




Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: bil@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 12 Feb 2018 22:00:02 +0000
Resent-Message-ID: <handler.30426.B30426.151847277014823 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.151847277014823
          (code B ref 30426); Mon, 12 Feb 2018 22:00:02 +0000
Received: (at 30426) by debbugs.gnu.org; 12 Feb 2018 21:59:30 +0000
Received: from localhost ([127.0.0.1]:40145 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1elM8H-0003r1-NA
	for submit <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:59:29 -0500
Received: from mx0b-00000d04.pphosted.com ([148.163.153.235]:54026)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bil@HIDDEN>) id 1elM8G-0003qu-Es
 for 30426 <at> debbugs.gnu.org; Mon, 12 Feb 2018 16:59:28 -0500
Received: from pps.filterd (m0102895.ppops.net [127.0.0.1])
 by mx0a-00000d04.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1CLwJZf032569; Mon, 12 Feb 2018 13:59:27 -0800
Received: from mx0a-00000d03.pphosted.com (mx0a-00000d03.pphosted.com
 [148.163.149.244])
 by mx0a-00000d04.pphosted.com with ESMTP id 2g3fajsexp-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 12 Feb 2018 13:59:27 -0800
Received: from pps.filterd (m0102881.ppops.net [127.0.0.1])
 by mx0a-00000d03.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1CLsnB7005436; Mon, 12 Feb 2018 13:59:26 -0800
Received: from codegreen7.stanford.edu (codegreen7.stanford.edu [171.67.224.9])
 by mx0a-00000d03.pphosted.com with ESMTP id 2g3fuyv29d-1
 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT);
 Mon, 12 Feb 2018 13:59:26 -0800
Received: from codegreen7.stanford.edu (localhost.localdomain [127.0.0.1])
 by codegreen7.stanford.edu (Postfix) with ESMTP id A37CB47;
 Mon, 12 Feb 2018 13:59:15 -0800 (PST)
Received: from smtp.stanford.edu (smtp3.stanford.edu [171.67.219.83])
 by codegreen7.stanford.edu (Postfix) with ESMTP id 975FB49;
 Mon, 12 Feb 2018 13:59:15 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtp.stanford.edu (Postfix) with ESMTPS id 7EEA51863A8;
 Mon, 12 Feb 2018 13:59:25 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (authenticated bits=0)
 by cm-mail.stanford.edu (8.14.4/8.14.4) with ESMTP id w1CLxO3h013608
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Mon, 12 Feb 2018 13:59:24 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Feb 2018 13:59:24 -0800
From: bil@HIDDEN
In-Reply-To: <87sha5q588.fsf@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 <874lmlrkgc.fsf@HIDDEN> <87sha5q588.fsf@HIDDEN>
Message-ID: <8d11fe9992e70af48db00d9a35a93a20@HIDDEN>
X-Sender: bil@HIDDEN
User-Agent: Roundcube Webmail/1.0.12
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on cm-mail.stanford.edu
x-proofpoint-stanford-dir: outbound
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-12_09:, , signatures=0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-12_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=559 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1711220000 definitions=main-1802120278
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Thanks very much for the informative answer!  I am not sure what
(* 0 +nan.0) should return.  I lean toward +nan.0 mainly because
I assume NaNs exist to indicate an error somewhere, and you want
that to be returned. For (* 0 +inf.0) I have no druthers.
For (/ 0.0 0) and (/ +nan.0 0) s7 throws a divide-by-zero error,
but I have no good reason for doing this.  In s7, I'd prefer
to say (/ x y ...) is equal to (/ x (* y ...)) in all cases.






Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 14 Feb 2018 20:56:01 +0000
Resent-Message-ID: <handler.30426.B30426.15186417103625 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: bil@HIDDEN
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.15186417103625
          (code B ref 30426); Wed, 14 Feb 2018 20:56:01 +0000
Received: (at 30426) by debbugs.gnu.org; 14 Feb 2018 20:55:10 +0000
Received: from localhost ([127.0.0.1]:43287 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1em457-0000wP-T7
	for submit <at> debbugs.gnu.org; Wed, 14 Feb 2018 15:55:10 -0500
Received: from world.peace.net ([50.252.239.5]:58896)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1em456-0000wC-PL
 for 30426 <at> debbugs.gnu.org; Wed, 14 Feb 2018 15:55:09 -0500
Received: from pool-72-93-29-93.bstnma.east.verizon.net ([72.93.29.93]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1em450-0007u3-D5; Wed, 14 Feb 2018 15:55:02 -0500
From: Mark H Weaver <mhw@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 <874lmlrkgc.fsf@HIDDEN> <87sha5q588.fsf@HIDDEN>
 <8d11fe9992e70af48db00d9a35a93a20@HIDDEN>
Date: Wed, 14 Feb 2018 15:54:28 -0500
In-Reply-To: <8d11fe9992e70af48db00d9a35a93a20@HIDDEN>
 (bil@HIDDEN's message of "Mon, 12 Feb 2018 13:59:24
 -0800")
Message-ID: <87r2pnnvgb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

bil@HIDDEN writes:

> Thanks very much for the informative answer!  I am not sure what
> (* 0 +nan.0) should return.  I lean toward +nan.0 mainly because
> I assume NaNs exist to indicate an error somewhere, and you want
> that to be returned.

It's a sensible position.  FWIW, my rationale is that for all exact
integers k, (* k x) => (+ x ...) with k copies of x in the arguments.
By that rule, (* 0 x) => (+).

It's certainly true that NaNs exist to indicate errors, but they might
not be propagated to the final result due to control flow, and for a
typical formal specification of multiplication-by-exact-integer
equivalent to the rule above, the NaN would not be propagated.

More generally, if the result would be the same for _any_ exact real
substituted in place of the NaN, then I believe it's justifiable to drop
the NaN.  R7RS-small states a similar rule in section 6.2.4:

  An arithmetic operation where one operand is NaN returns NaN, unless
  the implementation can prove that the result would be the same if the
  NaN were replaced by any rational number.

> For (* 0 +inf.0) I have no druthers.

> For (/ 0.0 0) and (/ +nan.0 0) s7 throws a divide-by-zero error,
> but I have no good reason for doing this.

For lack of a more comprehensive framework to decide corner cases
involving a mixture of exact and inexact arguments, I've found it useful
to use limits to decide the results of numerical operations involving
inexact zeroes or infinities.  Based on my reading of IEEE 754 and
related articles by Kahan, this is the approach that I've found is most
justifiable and consistent with IEEE 754.

For example, for (<op> 0.0 y ...), I take the limit of (<op> x y ...) as
x approaches zero from above, and similarly for 'x' in other argument
positions.  For -0.0, I take the limit as x approaches zero from below.
Similarly for the infinities.  This rule does not cover cases where more
than one argument is an inexact zero or infinity.

If one accepts this approach, then (/ 0.0 0) is undefined and
(* 0 +inf.0) is 0.

> In s7, I'd prefer to say (/ x y ...) is equal to (/ x (* y ...)) in
> all cases.

FWIW, I believe this is in violation of all RnRS at least as far back as
R3RS, which all specify that '/' returns the quotient of its arguments,
associating to the left.  On the other hand, I've not been shy to
deviate from RnRS when I thought it made sense to do so, so I can't
complain :)

     Regards,
       Mark




Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: bil@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 14 Feb 2018 22:11:02 +0000
Resent-Message-ID: <handler.30426.B30426.151864626110650 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.151864626110650
          (code B ref 30426); Wed, 14 Feb 2018 22:11:02 +0000
Received: (at 30426) by debbugs.gnu.org; 14 Feb 2018 22:11:01 +0000
Received: from localhost ([127.0.0.1]:43416 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1em5GV-0002lb-Ob
	for submit <at> debbugs.gnu.org; Wed, 14 Feb 2018 17:11:01 -0500
Received: from mx0a-00000d04.pphosted.com ([148.163.149.245]:57100)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bil@HIDDEN>) id 1em5GT-0002lT-8q
 for 30426 <at> debbugs.gnu.org; Wed, 14 Feb 2018 17:10:57 -0500
Received: from pps.filterd (m0102887.ppops.net [127.0.0.1])
 by mx0a-00000d04.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1EM91WP007288; Wed, 14 Feb 2018 14:10:56 -0800
Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com
 [148.163.153.234])
 by mx0a-00000d04.pphosted.com with ESMTP id 2g4we2r3gn-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Wed, 14 Feb 2018 14:10:55 -0800
Received: from pps.filterd (m0102882.ppops.net [127.0.0.1])
 by mx0a-00000d03.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
 w1EM9tTR014163; Wed, 14 Feb 2018 14:10:54 -0800
Received: from codegreen8.stanford.edu (codegreen8.stanford.edu
 [171.67.224.10])
 by mx0a-00000d03.pphosted.com with ESMTP id 2g44qtugye-1
 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT);
 Wed, 14 Feb 2018 14:10:54 -0800
Received: from codegreen8.stanford.edu (localhost.localdomain [127.0.0.1])
 by codegreen8.stanford.edu (Postfix) with ESMTP id 012DF5A;
 Wed, 14 Feb 2018 14:10:54 -0800 (PST)
Received: from smtp.stanford.edu (smtp1.stanford.edu [171.67.219.81])
 by codegreen8.stanford.edu (Postfix) with ESMTP id E938B5A;
 Wed, 14 Feb 2018 14:10:53 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by smtp.stanford.edu (Postfix) with ESMTPS id 625CE6FD26;
 Wed, 14 Feb 2018 14:10:53 -0800 (PST)
Received: from cm-mail.stanford.edu (cm-mail.stanford.edu [171.64.197.135])
 (authenticated bits=0)
 by cm-mail.stanford.edu (8.14.4/8.14.4) with ESMTP id w1EMAqgs010231
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
 Wed, 14 Feb 2018 14:10:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 14 Feb 2018 14:10:52 -0800
From: bil@HIDDEN
In-Reply-To: <87r2pnnvgb.fsf@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 <874lmlrkgc.fsf@HIDDEN> <87sha5q588.fsf@HIDDEN>
 <8d11fe9992e70af48db00d9a35a93a20@HIDDEN>
 <87r2pnnvgb.fsf@HIDDEN>
Message-ID: <7d3ad28781defb8921e66e6287581af8@HIDDEN>
X-Sender: bil@HIDDEN
User-Agent: Roundcube Webmail/1.0.12
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on cm-mail.stanford.edu
x-proofpoint-stanford-dir: outbound
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-14_08:, , signatures=0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, ,
 definitions=2018-02-14_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
 priorityscore=1501
 malwarescore=0 suspectscore=0 phishscore=4 bulkscore=0 spamscore=0
 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=391 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1711220000 definitions=main-1802140261
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

But if (* 0 x) is 0, you lose the notion that
(* exact inexact) is inexact.  So (* 0 +inf.0)
should be 0.0 or maybe +nan.0.  Similarly with
+nan.0, I suppose.






Message sent to bug-guile@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#30426: division inconsistency?
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Thu, 15 Feb 2018 07:36:02 +0000
Resent-Message-ID: <handler.30426.B30426.151868015729401 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30426
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: bil@HIDDEN
Cc: 30426 <at> debbugs.gnu.org
Received: via spool by 30426-submit <at> debbugs.gnu.org id=B30426.151868015729401
          (code B ref 30426); Thu, 15 Feb 2018 07:36:02 +0000
Received: (at 30426) by debbugs.gnu.org; 15 Feb 2018 07:35:57 +0000
Received: from localhost ([127.0.0.1]:43584 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1emE5F-0007e8-5J
	for submit <at> debbugs.gnu.org; Thu, 15 Feb 2018 02:35:57 -0500
Received: from world.peace.net ([50.252.239.5]:59956)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1emE5D-0007dv-Ad
 for 30426 <at> debbugs.gnu.org; Thu, 15 Feb 2018 02:35:55 -0500
Received: from pool-72-93-28-176.bstnma.east.verizon.net ([72.93.28.176]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1emE56-00048s-UI; Thu, 15 Feb 2018 02:35:49 -0500
From: Mark H Weaver <mhw@HIDDEN>
References: <afc4d9faa1402ebcac0c489efffe52e2@HIDDEN>
 <874lmlrkgc.fsf@HIDDEN> <87sha5q588.fsf@HIDDEN>
 <8d11fe9992e70af48db00d9a35a93a20@HIDDEN>
 <87r2pnnvgb.fsf@HIDDEN>
 <7d3ad28781defb8921e66e6287581af8@HIDDEN>
Date: Thu, 15 Feb 2018 02:35:14 -0500
In-Reply-To: <7d3ad28781defb8921e66e6287581af8@HIDDEN>
 (bil@HIDDEN's message of "Wed, 14 Feb 2018 14:10:52
 -0800")
Message-ID: <87inayogct.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Hi Bill,

bil@HIDDEN writes:

> But if (* 0 x) is 0, you lose the notion that
> (* exact inexact) is inexact.  So (* 0 +inf.0)
> should be 0.0 or maybe +nan.0.  Similarly with
> +nan.0, I suppose.

No, because (* 0 x) is equivalent to (+), where the x is not an input.
In fact, this specific case (multiplication by exact 0) is given as an
example where exact 0 may be returned even if the other argument is
inexact, by R4RS, R5RS, R6RS, and R7RS.

R4RS section 6.5.2, and R5RS section 6.2.2 (Exactness), state:

  With the exception of 'inexact->exact', the operations described in
  this section must generally return inexact results when given any
  inexact arguments.  An operation may, however, return an exact result
  if it can prove that the value of the result is unaffected by the
  inexactness of its arguments.  For example, multiplication of any
  number by an exact zero may produce an exact zero result, even if the
  other argument is inexact.

R6RS section 11.7.1 (Propagation of exactness and inexactness) states:

  One general exception to the rule above is that an implementation may
  return an exact result despite inexact arguments if that exact result
  would be the correct result for all possible substitutions of exact
  arguments for the inexact ones.  An example is (* 1.0 0) which may
  return either 0 (exact) or 0.0 (inexact).

R7RS section 6.2.2 (Exactness) states:

  Except for exact, the operations described in this section must
  generally return inexact results when given any inexact arguments.  An
  operation may, however, return an exact result if it can prove that
  the value of the result is unaffected by the inexactness of its
  arguments.  For example, multiplication of any number by an exact zero
  may produce an exact zero result, even if the other argument is
  inexact.

  Specifically, the expression (* 0 +inf.0) may return 0, or +nan.0, or
  report that inexact numbers are not supported, or report that
  non-rational real numbers are not supported, or fail silently or
  noisily in other implementation-specific ways.

I'm quite sensitive to this issue, so sensitive that I decided to change
Guile several years ago so that (* 0 1.0) would return 0.0 instead of 0.
My rationale was that if the 1.0 were replaced by +inf.0 or +nan.0, then
by IEEE 754 the result should be +nan.0, and therefore that the result
was not the same regardless of the value of the inexact argument.  I
didn't care that R[4567]RS specifically gave this as an example where an
exact 0 may be returned, because I judged that it violated the
principles of the exactness propagation, and I don't want to return an
exact result unless it could in principle be _proved_ to be correct.

The new language in R6RS is what changed my mind.  In R6RS, you may
return an exact result if it "would be the correct result for all
possible substitutions of _exact_ arguments for the inexact ones."  So,
we needn't consider what would happen if +inf.0 or +nan.0 were put in
place of the 1.0 in (* 0 1.0), because +inf.0 and +nan.0 are not exact.

I think this is the right principle.  In mathematics, all real numbers
are finite; there are no infinities and no NaNs.  I regard the inexact
infinities as merely inexact representations of very large finite real
numbers.

What do you think?

     Regards,
       Mark





Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.