More on semantics of opPow: return type

[Lars T. Kyllingstad]

Lars T. Kyllingstad wrote:
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> As has been mentioned in previous posts, a ^^ b should be right 
>>> associative and have a precedence between multiplication and unary 
>>> operators. That much is clear.
>>>
>>>
>>> Operations involving integers are far less obvious (and are actually 
>>> where a major benefit of an operator can come in).
>>>
>>> Using the normal promotion rules, 10^^2 is an integer. The range 
>>> checking already present in D2 could be extended so that the compiler 
>>> knows it'll even fit in a byte. This gets rid of one of the classic 
>>> annoyances of C pow:  int x = pow(2, 10); doesn't compile without a 
>>> cast.
>>>
>>> But the difficult question is, what's the type of 10^^-2 ? Should it 
>>> be an error? (since the result, 0.01, is not representable as an 
>>> integer). Should it return zero? (just as 1/2 doesn't return 0.5). 
>>> For an example of these semantics, see 
>>> http://www.tcl.tk/cgi-bin/tct/tip/123.html).
>>> Or should it return a double?
>>> Or should 10^^2 also be a double, but implicitly castable to byte 
>>> because of the range checking rules?
>>>
>>> I currently favour making it an error, so that the normal promotion 
>>> rules apply. It seems reasonable to me to require a cast to floating 
>>> point in there somewhere.
>>> This is analagous to the similar case f ^^ 0.1; where f is known to 
>>> be negative. This gives a complex result, creating a run-time error 
>>> (returns a NaN). But, there's no standard error and no NaNs for 
>>> integer underflow.
>>>
>>> One could also make int ^^ uint defined (returning an int), but not 
>>> int ^^ int. Again thanks to range checking, int ^^ uint ^^ uint would 
>>> work, because although uint ^^ uint is an int, it's known to be 
>>> positive, so would implicitly convert to int. But would making int ^^ 
>>> int illegal, make it too much of an annoying special case?
>>>
>>> I strongly suspect that x^^y, where x and y are integers, and the 
>>> value of y is not known at compile time, is an extremely rare operation.
>>>
>>> Also, should int^^uint generate some kind of overflow error? Although 
>>> other arithmeic integer operators don't, it's fantastically easy to 
>>> hit an overflow with x^^y. Unless x is 1, y must be tiny (< 64 to 
>>> avoid overflowing a ulong).
>>
>> Nice analysis. IMHO this should lead us to reconsider the necessity of 
>> "^^" in the first place. It seems to be adding too little real value 
>> compared to the complexity of defining it.
>>
>> Andrei
> 
> 
> It adds a lot of value to the ones that actually use it, even though you 
> may not be one of them. Exponentiation is extremely common in numerics.
> 
> Here are some statistics for you: A Google code search (see below) for 
> FORTRAN code using the power operator **, which until recently didn't 
> have a D equivalent, yields roughly 56100 results.
> 
> A search for the FORTRAN equivalents of << yield 400 results for ILS() 
> and 276 results for LSHIFT(). Yet, left shift apparently deserves a 
> place in D.

FORTRAN also has the ISHFT() shift function, which gives about 2000 
results on Google. Still way less than for **.


> (I've used http://www.google.com/codesearch, with the following search 
> strings for **, ILS and LSHIFT, respectively:
> 
>     [0-9a-zA-Z)]\*\*[0-9a-zA-Z(] lang:fortran
>     ils\([0-9a-zA-Z] lang:fortran
>     lshift\([0-9a-zA-Z] lang:fortran

      ishft\([0-9a-zA-Z] lang:fortran

-Lars