Semantics of ^^

[Don]

Bill Baxter wrote:
> On Tue, Dec 8, 2009 at 2:32 AM, Don <nospam at nospam.com> wrote:
>> Based on everyone's comments, this is what I have come up with:
>>
>> --------------------
>> x ^^ y is right associative, and has a precedence intermediate between
>> multiplication and unary operators.
> 
> Is that consistent with math?   I think in math they usually write
> (-1)^n with parens.
> See for example the sin power series here:
> http://en.wikipedia.org/wiki/Power_series

Hmm, that's what's

> 
> What's the rationale for going against math here?
> 
>> * The type of x ^^ y is the same as the type of x * y.
> 
> Like it.
> 
>> * If y == 0,  x ^^ y is 1.
> 
> Need to mention what happens when x is also 0.

No.  0^^0 is 1, as well.

>> * If both x and y are integers, and y > 0,  x^^y is equivalent to
>>   { auto u = x; foreach(i; 1..y) { u *= x; } return u; }
>> * If both x and y are integers, and y < 0, an integer divide error occurs,
>> regardless of the value of x. This error is detected at compile time, if
>> possible.
> 
> Can you explain why you think that's necessary?  Seems like going too
> far towards a nanny compiler for no particularly good reason.
 >
> The fact that 2^^-1 isn't particularly useful doesn't make it
> particularly error prone.  No more so than integer division when the
> person meant floating point division.

Integer division is a well defined operation. 2^^-1 is *never* sensible.

   I just find it unexpected that
> a language would single out exponentiation for this kind of treatment.
> 
>> * If either x or y are floating-point, the result is pow(x, y).
>> --------------------
>> Rationale:
>> (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.

> 
>> In all other cases, a negative exponent
>> indicates an error; it should be rewritten as (cast(real)x) ^^ y. Making
>> these cases errors makes everything much simpler, and allows the compiler to
>> use range propagation on the value of y to detect most exponentiation errors
>> at compile time. (If those cases are legal, the compiler can't generate an
>> error on x^^-2, because of the possibility that x might be 1 or -1).
> 
> 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.

> 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.