ANSI #raisedToInteger:

Andrew C. Greenberg werdna at mucow.com
Tue Dec 17 12:14:52 UTC 2002


Indeed, Richard's reparse (rewrite) makes far more sense than the 
standard language.  His clarification should be forwarded to the powers 
that be.

By way of explanation how such things can happen, let us remember the 
fourth law of thermodynamics -- that the number of nontrivial programs 
that are bug-free is zero.  An analogous principle is that the number 
of nontrivial specifications that are bug-free (in the abstract 
truth-seeking sense -- they cannot have "bugs," strictly speaking since 
they specify the result) is likewise zero -- these specifications are 
not final because they are infallible, they are infallible because they 
are final.  Since the spec has not been used as a sole guide for many 
new Smalltalk implementations, it is unsurprising that "spec-bugs" 
exist and will remain for awhile -- there isn't a syntax compiler or 
test suite that facilitates finding bugs in these documents, only 
code-readings such as that of Richard will do that.

No specification has been immune from these problems -- some are more 
at risk than others.

This is the reason why the ANSI standard is not a gospel -- and that 
mere word-lawyering from that document probably should not inform 
beyond technical suggestion any dramatic changes in Squeak and standard 
Smalltalk libraries.

On Monday, December 16, 2002, at 10:00 PM, Richard A. O'Keefe wrote:

> I've now got a copy of the published version of the ANSI Smalltalk
> standard.  Has too much study driven me mad, or is the following
> method description seriously broken?
>
> 5.6.2.28 Message:  raisedToInteger: operand
>   Synopsis
>     Answer the receiver raised to the power operand.
>   Definition: <number>
>     Answer the receiver raised to the power operand,
>     which must be a whole number.
>     If the operand is a whole number greater than or equal to zero,
>     then the result is the receiver raised to the power operand.
>>>> If operand is a negative whole number, then the result is
>>>> equivalent to the reciprocal of the absolute value of the
>>>> receiver raised to the power operand.
>
>    ...
>
> The highlighted sentence is ambiguous.
> Suppose we have (p raisedToInteger: q) where p is a positive
> integer and q is a negative integer.
>
> Reading 1:
>     The result is ... the reciprocal of ((the absolute value of
>     the receiver) raised to the power operand).
>
>       ^((self abs) raisedToInteger: operand) reciprocal
>
> Reading 2:
>     The result is ... (the reciprocal of (the absolute value of
>     the receiver)) raised to the power operand.
>
>      ^(self abs reciprocal) raisedToInteger: operand
>
> Surely it should be
>     The result is ... (the reciprocal of the receiver) raised to
>     the power (the absolute value of operand).
>
>      ^self reciprocal raisedTo: operand abs
>
> or else
>     The result is ... the reciprocal of (the receiver raised to
>     the power (the absolute value of operand)).
>
>      ^(self raisedTo: operand abs) reciprocal
>
> There are other glitches I laughed at in the 1.9 draft, but
> they don't seem quite as funny when I've paid for the final version
> and they are still there.
>
>




More information about the Squeak-dev mailing list