On Tue, Dec 8, 2009 at 9:40 AM, Andrei Alexandrescu <[email protected]> wrote: > Bill Baxter wrote: >> >> On Tue, Dec 8, 2009 at 12:01 AM, Andrei Alexandrescu >> <[email protected]> wrote: >> >>> What I'd like would be a solid rationale for the choice. Off the top of >>> my >>> head and while my hat is off to your math skills and experience, I have >>> trouble understanding the soundness of making int^^int yield an int, for >>> the >>> following reason: >>> >>> For all negative exponents, the result is zero, except when the base is 1 >>> or >>> -1. So I guess I'd suggest you at least make the exponent unsigned - the >>> result is of zero interest (quite literally) for all negative exponents. >>> If >>> that behavior is interesting, it would be great if you provided a >>> rationale >>> for it. >> >> The rationale (exponentiale?) for it is consistency. > > Consistency is a good rationale, but math simply doesn't work that way. > Matrix multiplication could have been defined to be consistent with matrix > addition, but it ain't, because multiplication defined that way is > uninteresting.
I'm not arguing consistency with math. I'm arguing consistency in the language. You're talking about consistency within math itself. >> Yeh, it's of >> zero interest. But it's simple and consistent and doesn't require a >> bunch of new rules. In the world of ints, small positive powers >> really are the only interesting case. (And not just two and three -- >> sometimes you'll see 2**N used to compute buffer sizes in Python. Or >> at least that's what I observed in the code searches people posted. >> Arguably a more direct expression of intent than 1<<N.) > > I agree. Then why not require the exponent to be unsigned during > compilation? Don said he'd want negative exponent to throw a runtime > exception. Why? He figures it's usually an error, so he wants to be helpful. But he's killing a useful feature along with it. >> You seem to be gunning to make some unneccesarily complicated rules up >> to handle a case that's not really important, but then at the same >> time argue that things are getting too complicated so we better axe >> the whole feature. It doesn't really make sense. > > It does. What I said was that we could be in one of two extremes: ^^ is a > simple slam dunk, add it for convenience, versus ^^ is hard to type > properly, but compiler support can do it. A wishy-washy middle ground where > it's there but not doing something principled... that I don't like. But then > again I defer the decision to Don. Ok, now I understand your position better. And my position is that we should keep it consistent with how division is treated. No fancy type guessing based on arguments' values. int/int -> int. Doing something more sophisticated with typeof(int^^int) only makes sense to me if we do the same for division. Otherwise you're creating a lopsided an inconsistent language feature. >> To make a comparison, << and >> aren't very useful for floating point >> numbers, does that mean they shouldn't be in the language? > > Wrong argument. << and >> are closed over integrals. I see a mistaken > argument, I point it out :o). I have no idea what you mean by that. You said that raising integers to negative powers wasn't useful and so it casts a dubious light over the whole feature. I'm saying the fact that an operator isn't universally useful does not imply it is useless. For another example, the fact that ~ isn't useful for numbers at all hasn't dulled our enthusiasm for it, because it *is* useful in the places where it was intended to be useful. Similarly ^^ is useful for floats, and some subset of integers. >> In >> contrast ^^ is useful for both floats and ints with small positive >> powers. No, not all ints, but that's better versatility than << and >>>> >>>> at least. > > I agree. Then at least why not make the type of the exponent unsigned? That > gives the type system a fighting chance (via e.g. value range propagation). > Give Willy a chance! Honestly, I don't really understand this concern with range propagation. Seems to me that allowing a negative exponent doesn't much expand the range, if a truncation rule is used. The result is either undefined, 0 or 1. The range is much greater with a non-negative exponent. Could be undefined, zero, or most any negative or positive number. --bb
