Re: [Scheme-reports] Definition of expt (was #391 - a selection of error predicates)

[Alex Shinn <alexshinn@x>]

On Wed, Aug 8, 2012 at 8:44 PM, Mark H Weaver <mhw@x> wrote:
> On 08/08/2012 02:49 AM, Alex Shinn wrote (on the WG1 list):
>>
>> These predicates seem random, reflecting only the
>> historical precedent of what was stated as "signals
>> an error" vs "is an error".  I'm not even convinced that
>> distinction was made by design rather than the
>> stylistic convention of the editors at the time.
>>
>> For expt, in particular, we added this note ourselves,
>> and the actual text is:
>>
>>    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.
>>
>> Apart from the wording being a clumsy, saying
>> an "error is signalled _or_ an unspecified result
>> is returned" is the same as saying "the result is
>> an error."
>
>
> The text does not say "or an unspecified result is returned".  It says "or
> an unspecified _number_ is returned".  Therefore, it is not the same.

Not quite the same, but close enough.
We should signal an error, or do something
unspecified, not one or the other.

>> I propose changing the text to:
>>
>>    0^z is 1 if z = 0, and 0 if (real-part z) is positive.
>>    It is an error if (real-part z) is negative.
>
>
> You've made two questionable changes to the meaning of this definition,
> beyond the description of what happens in the error/unspecified case.
>
> 1. The current text uses "0.0" and "1.0" which suggests inexact numbers.
> You've changed these to exact numbers.   I interpret the current text to
> apply only when the base is an _inexact_ zero, and to specify inexact
> results.  I interpret your proposed text as mandating exact return values,
> and possibly also applying when the base is an exact zero.

This was very much intentional.  The current text
was a derivation from R5RS that was never voted
on - I simply fixed it.

The general rule we've been taking is exact zero
causes errors, inexact zero returns whatever the
floating point processor returns.

> 2. In the current text, the error/unspecified case consists of the following
> possibilities: (real-part z) is negative, or (real-part z) is zero and
> (imag-part z) is non-zero.  Your change in wording now fails to specify the
> behavior in the latter case.

It's still a draft wording on the WG members list,
I was hoping another member would refine it.

How about:

   0^z is 1 if z = 0, 0 if (real-part z) is positive,
   and an error otherwise.

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports