On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter <[email protected]> wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don <[email protected]> wrote:
[snip]
* 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. I just find it unexpected that
a language would single out exponentiation for this kind of treatment.
I was also wondering about this. If it can't be detected at compile time,
is the result 0?
[snip]
(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).
[snip]
I think n is always non-negative in the trig series, but some Laurent
series use negative n values. So (-1)^^n might be useful for negative n,
but you could always rewrite it as (n%2 ? -1 : 1) or ~(n&1)+1.
