GNU logs - #16365, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#16365: (* 0 +inf.0) rationale is flawed
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 06 Jan 2014 00:18:01 +0000
Resent-Message-ID: <handler.16365.B.138896745327118 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 16365 <at> debbugs.gnu.org
Date: Mon, 6 Jan 2014 00:17:19 +0000
From: Zefram <zefram@HIDDEN>
Message-ID: <20140106001719.GI21945@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Commit 5e7918077a4015768a352ab19e4a8e94531bc8aa says

      A note on the rationale for (* 0 +inf.0) being a NaN and not exact 0:
      The R6RS requires that (/ 0 0.0) return a NaN value, and that (/ 0.0)
      return +inf.0.  We would like (/ x y) to be the same as (* x (/ y)),

This identity doesn't actually hold.  For example, on guile 2.0.9 with
IEEE double flonums:

scheme@(guile-user)> (/ (expt 2.0 -20) (expt 2.0 -1026))
$36 = 6.857655085992111e302
scheme@(guile-user)> (* (expt 2.0 -20) (/ (expt 2.0 -1026)))
$37 = +inf.0

This case arises because the dynamic range of this flonum format is
slightly asymmetric: 2^-1026 is representable, but 2^1026 overflows.

So the rationale for (* 0 +inf.0) yielding +nan.0 is flawed.  As the
supposed invariant and the rationale are not in the actual documentation
(only mentioned in the commit log) this is not necessarily a bug.
But worth thinking again to determine whether the case for adopting
the flonum behaviour here is still stronger than the obvious case for
the exact zero to predominate.  (Mathematically, multiplying zero by an
infinite number does yield zero.  Let alone multiplying it by a merely
large finite number, which is what the flonum indefinite `infinity'
really represents.)

-zefram

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Zefram <zefram@HIDDEN>
Subject: bug#16365: Acknowledgement ((* 0 +inf.0) rationale is flawed)
Message-ID: <handler.16365.B.138896745327118.ack <at> debbugs.gnu.org>
References: <20140106001719.GI21945@HIDDEN>
X-Gnu-PR-Message: ack 16365
X-Gnu-PR-Package: guile
Reply-To: 16365 <at> debbugs.gnu.org
Date: Mon, 06 Jan 2014 00:18: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 16365 <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
16365: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16365
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#16365: (* 0 +inf.0) rationale is flawed
Resent-From: Andy Wingo <wingo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Tue, 21 Jun 2016 12:43:02 +0000
Resent-Message-ID: <handler.16365.B16365.14665129309053 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: mhw@HIDDEN
Cc: Zefram <zefram@HIDDEN>, 16365 <at> debbugs.gnu.org
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc
 :subject:references:date:in-reply-to:message-id:mime-version
 :content-type; q=dns; s=sasl; b=u0Mkq+0RatoPt8Ekg2uBBrFISv06tsz9
 WULj+fTxppwfF5bOjGu/dEy4QknJ9acMqPZ1F1H7JQNKffwnrSBQrQ7Yon7EhM/A
 4brgnYcrpnaKQGEP25rflAENsxFbtsDL5WJVr6T0ZsA/BfecopfUP4S0UbuwTyK0
 VoZ1tXm1qUs=
From: Andy Wingo <wingo@HIDDEN>
References: <20140106001719.GI21945@HIDDEN>
Date: Tue, 21 Jun 2016 14:41:58 +0200
In-Reply-To: <20140106001719.GI21945@HIDDEN> (zefram@HIDDEN's message of
 "Mon, 6 Jan 2014 00:17:19 +0000")
Message-ID: <87r3bqzpbd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Thoughts, Mark?

On Mon 06 Jan 2014 01:17, Zefram <zefram@HIDDEN> writes:

> Commit 5e7918077a4015768a352ab19e4a8e94531bc8aa says
>
>       A note on the rationale for (* 0 +inf.0) being a NaN and not exact 0:
>       The R6RS requires that (/ 0 0.0) return a NaN value, and that (/ 0.0)
>       return +inf.0.  We would like (/ x y) to be the same as (* x (/ y)),
>
> This identity doesn't actually hold.  For example, on guile 2.0.9 with
> IEEE double flonums:
>
> scheme@(guile-user)> (/ (expt 2.0 -20) (expt 2.0 -1026))
> $36 = 6.857655085992111e302
> scheme@(guile-user)> (* (expt 2.0 -20) (/ (expt 2.0 -1026)))
> $37 = +inf.0
>
> This case arises because the dynamic range of this flonum format is
> slightly asymmetric: 2^-1026 is representable, but 2^1026 overflows.
>
> So the rationale for (* 0 +inf.0) yielding +nan.0 is flawed.  As the
> supposed invariant and the rationale are not in the actual documentation
> (only mentioned in the commit log) this is not necessarily a bug.
> But worth thinking again to determine whether the case for adopting
> the flonum behaviour here is still stronger than the obvious case for
> the exact zero to predominate.  (Mathematically, multiplying zero by an
> infinite number does yield zero.  Let alone multiplying it by a merely
> large finite number, which is what the flonum indefinite `infinity'
> really represents.)
>
> -zefram

Message sent to bug-guile@HIDDEN:

Subject: bug#16365: (* 0 +inf.0) rationale is flawed
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: Tue, 21 Jun 2016 13:58:01 +0000
Resent-Message-ID: <handler.16365.B16365.146651747317418 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Andy Wingo <wingo@HIDDEN>
Cc: Zefram <zefram@HIDDEN>, 16365 <at> debbugs.gnu.org
From: Mark H Weaver <mhw@HIDDEN>
References: <20140106001719.GI21945@HIDDEN> <87r3bqzpbd.fsf@HIDDEN>
Date: Tue, 21 Jun 2016 09:57:32 -0400
In-Reply-To: <87r3bqzpbd.fsf@HIDDEN> (Andy Wingo's message of "Tue, 21 Jun
 2016 14:41:58 +0200")
Message-ID: <87vb12skz7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Andy Wingo <wingo@HIDDEN> writes:
> Thoughts, Mark?

Sorry for the long delay on this, but briefly, I agree that my rationale
was flawed, and that we should make (* 0 <anything>) == 0 in all cases
in 2.2.  I also suspect that (/ 0 <anything_but_exact_0>) should be 0,
although that conflicts with R6RS.  We should probably investigate the
rationale behind R6RS's decision to specify that (/ 0 0.0) returns a NaN
before changing that, though.

I hope to work more on this soon.

      Thanks,
        Mark


> On Mon 06 Jan 2014 01:17, Zefram <zefram@HIDDEN> writes:
>
>> Commit 5e7918077a4015768a352ab19e4a8e94531bc8aa says
>>
>>       A note on the rationale for (* 0 +inf.0) being a NaN and not exact 0:
>>       The R6RS requires that (/ 0 0.0) return a NaN value, and that (/ 0.0)
>>       return +inf.0.  We would like (/ x y) to be the same as (* x (/ y)),
>>
>> This identity doesn't actually hold.  For example, on guile 2.0.9 with
>> IEEE double flonums:
>>
>> scheme@(guile-user)> (/ (expt 2.0 -20) (expt 2.0 -1026))
>> $36 = 6.857655085992111e302
>> scheme@(guile-user)> (* (expt 2.0 -20) (/ (expt 2.0 -1026)))
>> $37 = +inf.0
>>
>> This case arises because the dynamic range of this flonum format is
>> slightly asymmetric: 2^-1026 is representable, but 2^1026 overflows.
>>
>> So the rationale for (* 0 +inf.0) yielding +nan.0 is flawed.  As the
>> supposed invariant and the rationale are not in the actual documentation
>> (only mentioned in the commit log) this is not necessarily a bug.
>> But worth thinking again to determine whether the case for adopting
>> the flonum behaviour here is still stronger than the obvious case for
>> the exact zero to predominate.  (Mathematically, multiplying zero by an
>> infinite number does yield zero.  Let alone multiplying it by a merely
>> large finite number, which is what the flonum indefinite `infinity'
>> really represents.)
>>
>> -zefram

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#16365: (* 0 +inf.0) rationale is flawed
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Tue, 21 Jun 2016 14:22:01 +0000
Resent-Message-ID: <handler.16365.B16365.146651889619618 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16365
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: Andy Wingo <wingo@HIDDEN>, 16365 <at> debbugs.gnu.org
Received: via spool by 16365-submit <at> debbugs.gnu.org id=B16365.146651889619618
          (code B ref 16365); Tue, 21 Jun 2016 14:22:01 +0000
Received: (at 16365) by debbugs.gnu.org; 21 Jun 2016 14:21:36 +0000
Received: from localhost ([127.0.0.1]:49851 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1bFMYa-00056M-6R
	for submit <at> debbugs.gnu.org; Tue, 21 Jun 2016 10:21:36 -0400
Received: from river.fysh.org ([87.98.248.19]:43731 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <zefram@HIDDEN>) id 1bFMYX-00056B-QC
 for 16365 <at> debbugs.gnu.org; Tue, 21 Jun 2016 10:21:34 -0400
Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian))
 id 1bFMYU-00034A-24; Tue, 21 Jun 2016 15:21:30 +0100
Date: Tue, 21 Jun 2016 15:21:30 +0100
From: Zefram <zefram@HIDDEN>
Message-ID: <20160621142130.GA1170@HIDDEN>
References: <20140106001719.GI21945@HIDDEN> <87r3bqzpbd.fsf@HIDDEN>
 <87vb12skz7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87vb12skz7.fsf@HIDDEN>
X-Spam-Score: -1.4 (-)
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: -1.4 (-)

Mark H Weaver wrote:
>         I also suspect that (/ 0 <anything_but_exact_0>) should be 0,
>although that conflicts with R6RS.  We should probably investigate the
>rationale behind R6RS's decision to specify that (/ 0 0.0) returns a NaN
>before changing that, though.

I think R6RS makes sense for (/ 0 0.0).  A flonum zero really represents
a range of values including both small non-zero numbers and actual zero.
The mathematical result of the division could therefore be either zero or
undefined.  To return zero for it would be picking a particular result,
on the assumption that the flonum zero actually represented a non-zero
value, and that's not justified.  So to use the flonum behaviour seems
the best thing available.

(/ 0 3.5) is a different case.  Here the mathematical result is an
exact zero, and I'm surprised that R6RS specifies that this should be
an inexact zero.  This seems inconsistent with (* 1.0 0), for which it
specifies that the result may be either 0 or 0.0.

I'd also question R6RS in the related case of (/ 0.0 0).  Mathematically
this division is definitely an error, regardless of whether the dividend
represents zero or a non-zero number.  So it would make sense for this
to raise an exception in the same manner as (/ 3 0) or (/ 0 0), rather
than get flonum treatment as R6RS specifies.

But deviating from R6RS, even with a good rationale for other behaviour,
would be a bad idea.  The questionable R6RS requirements are not crazy,
just suboptimal.  The case I originally raised, (* 0 +inf.0), is one
for which R6RS offers the choice.

-zefram

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.