Semantics of ^^

Denis Koroskin 2korden at gmail.com
Tue Dec 8 03:21:55 PST 2009


On Tue, 08 Dec 2009 13:32:26 +0300, 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.
>
> * The type of x ^^ y is the same as the type of x * y.
> * If y == 0,  x ^^ y is 1.
> * 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.
> * 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. 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).
> 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.
>
> (2) USE OF THE INTEGER DIVIDE ERROR
> Note that on x86 at least, a hardware "integer divide error", although  
> commonly referred to as "division by zero", also occurs when the DIV  
> instruction, which performs uint = ulong/uint, results in a value  
> greater than uint.max. Raising a number to a negative power does involve  
> a division, so it seems to me not unreasonable to use it for this case  
> as well.
> Note that 0 ^^ -1 is a division by zero.
> This means that, just as you should check that y!=0 before performing  
> x/y, you should check that y>=0 before performing x^^y.
>
> (3) OVERFLOW
> int ^^ int returns an int, not a long. Although a long would allow  
> representation of larger numbers, even doubling the number of bits  
> doesn't help much in avoiding overflow, because x^^y is exponential.  
> Even a floating-point representation can easily overflow:
> 5000^5000 easily overflows an 80-bit real.
> So, it's preferable to retain the simplicity that typeof(x^^y) is  
> typeof(x*y).
>

Looks solid. Just a quick question: is ^^ going to stay as opPow, or is it  
about to join the opBinary party?



More information about the Digitalmars-d mailing list