[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Definition of expt (was #391 - a selection of error predicates)
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.
0^z is 1 if z = 0, 0 if (real-part z) is positive,
and an error otherwise.
Scheme-reports mailing list