[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] [scheme-reports-wg1] John Cowan's votes and rationales on the seventh ballot

On 09/18/2012 11:40 PM, Alex Shinn wrote:
> On Wed, Sep 19, 2012 at 11:42 AM, Arthur A. Gleckler
> <scheme@x>  wrote:
>> On Tue, Sep 18, 2012 at 12:44 AM, John Cowan<cowan@x>  wrote:
>>> #121 The semantics of expt for zero bases has been refined
>>> Preferences: r5rs-error, r5rs
>>> Rationale: I agree that the R6RS rule makes no sense in an R7RS
>>> context. However, it's worth saying explicitly that the oddball zero
>>> cases are errors.
>> I don't understand.  I seem to remember you pointing this out before, but it
>> hasn't been fixed: the language for the r5rs-error option is exactly the
>> same as that for r6rs:
>>    0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive.
>>    For other cases in which the first argument is zero, either
>>    an error is signalled or an unspecified number is returned.
>> Should that read this way instead?:
>>    0.0^z is 1.0 if z = 0.0, and 0.0 if (real-part z) is positive.
>>    It is an error for the first argument to be zero in other cases.
>> Or am I misunderstanding the intent of this ballot item?
> I prefer my earlier wording:
>       The value of 0^z is 1 if (zero? z), 0 if (real-part z)
>       is positive, and an error otherwise.  Similarly for 0.0^z,
>       with inexact results.

This wording has serious flaws.  It suggests that for the cases 
specified above, the exactness of the result depends only on the 
exactness of the base.  For example, it suggests that (expt 0 0.0) => 1 
and (expt 0.0 0) => 1.0.

On the contrary, (expt <anything> 0) should yield an exact 1, and the 
result of (expt 0 0.0) certainly should not be exact.

Furthermore, I challenge anyone to justify (= 1 (expt 0 0.0)), or for 
that matter the claim that (expt 0 <non-integer>) is well-defined.  I'm 
not aware of any established definition for 'expt' that can justify 
these claims.


Scheme-reports mailing list