More on semantics of opPow: return type

[Bill Baxter]

On Tue, Dec 8, 2009 at 9:40 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Tue, Dec 8, 2009 at 12:01 AM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> 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