Semantics of ^^

Bill Baxter wbaxter at gmail.com
Wed Dec 9 08:25:52 PST 2009


On Tue, Dec 8, 2009 at 7:24 PM, Don <nospam at nospam.com> wrote:
>>> * If y == 0,  x ^^ y is 1.
>>
>> Need to mention what happens when x is also 0.
>
> No.  0^^0 is 1, as well.

Is it?  That's rather embarrassing for Wolfram Alpha, then (and
presumably Mathematica, too) since they have it as "indeterminate":
   http://www.wolframalpha.com/input/?i=0^0

>>> (1) Although the following special cases could be defined...
>>>  * If x == 1,  x ^^ y is 1
>>>  * If x == -1 and y is even, x^^y == 1
>>>  * If x == -1 and y is odd, x^^y == -1
>>> ... they are not sufficiently useful to justify the major increase in
>>> complexity which they introduce.
>>
>> Hmm, I'm not so sure about that.  I saw examples of this being used
>> even in the small sampling of search results from Python and Fortran
>> code that I looked at.  Many mathematical constructs are defined as
>> having a leading sign of (-1)^^n  (like the sin series formula linked
>> above).
>
> Yes, but n is always positive in those formulae.

Well, non-negative actually.
But yeh, that is true as far as the ones I know, too.

>> I didn't see this error as adding much value when there was nothing
>> clearly lost from it.  But here you're showing there is a real price
>> to pay for this nanny compiler behavior.   To me that makes the error
>> clearly not worth the price of admission.  I also think that since 0^0
>
> Rubbish. 0^^0 is 1.

Yeh, again Wolfram steered me wrong there, if you correct about that.


>> and 0^-1 and such are mathematically undefined, careful users of opPow
>> will already have to put some if() check before blindly doing an x^^y.
>>  Instead of
>>   if(x!=0 || y!=0)  x^^y;
>> the people who care can just change the check to
>>   if(x!=0 || y>0) x^^y;
>>
>> Doesn't changing that one operator there doesn't seem like an undue
>> burden upon those who are careful checkers of their values.
>>
>>> Also note that making it an error leaves open the possibility of changing
>>> it
>>> to a non-error later, without breaking code; but going from non-error to
>>> error would be more difficult.
>>
>> I think it's pretty clear that the error goes too far right now
>> without taking a wait-and-see stance.
>
> Do you realize you are asking for ^^ to be removed? I'm not joking. Walter's
> ready to pull it out. Please reconsider.

Walter's ready to pull it if you don't make negative powers on
integers an error?
Nope, didn't realize that.

Anyway, I've made my objections clear I think, so I won't reiterate.
Basically I just want to KISS, and be consistent with how / works, and
I think you guys get that but reject it.  Ok.

--bb



More information about the Digitalmars-d mailing list