bug#16365: (* 0 +inf.0) rationale is flawed

bug#16365: (* 0 +inf.0) rationale is flawed

[Zefram]

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

bug#16365: (* 0 +inf.0) rationale is flawed

[Andy Wingo]

Thoughts, Mark?

On Mon 06 Jan 2014 01:17, Zefram <zefram@fysh.org> 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

bug#16365: (* 0 +inf.0) rationale is flawed

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> 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@fysh.org> 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

bug#16365: (* 0 +inf.0) rationale is flawed

[Zefram]

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