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

[Mark H Weaver]

Andy Wingo <address@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 <address@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