issue 7006 - std.math.pow (integral, integral) crashes on negative exponents

[Patrick Schluter]

On Tuesday, 17 December 2019 at 13:39:13 UTC, Dominikus Dittes 
Scherkl wrote:
> On Tuesday, 17 December 2019 at 12:31:15 UTC, Timon Gehr wrote:
>>> I still don't understand
>>> why anybody want a function with signature
>>> 
>>> int pow(int, int)
>>> ...
>>
>> You are apparently not aware that std.math.pow is the 
>> implementation of the built-in `^^` operator. Removing it is 
>> not even on the table, it should just work correctly.
>
> Did I suggest to remove it? NO.
> But I'm of the opinion that having each internal operator 
> returning the same type as the given types is not always useful.
> ^^ should result in a real if the exponent is outside ubyte 
> range.
> Is this wrong? Am I crazy?
>
> Ok, this would be a huge language change, so I agree.
> giving x^^negative_exp == 0 is something we could do.
>
>>> I think
>> You are wrong.
> Please no ad hominem attacks!

That's not an ad hominem. That's just a statement of opinion. It 
would be ad hominem if something about you was the justification 
of the wrongness. You're wrong because your name is too long or 
because you have a big nose etc.



>
>>
>>> there are only two interesting cases:
>>> 
>>> int pow(int, ubyte)
>>>  > and
>>> 
>>> complex pow(complex, complex)
>>> ...
>>
>> Those cases already work fine, and they are off-topic.
> No, they do not work fine, because an implausible input range 
> for the exponent is defined.
> I still think this should be fixed.
>
>> As I am stating for the third time now, there are x such that 
>> `pow(x,int.max)` and/or `pow(x,int.min)` neither overflow nor 
>> cause any rounding.
> Yes, the cases with x == -1, 0 or 1. And only them.
> Maybe it should be fixed for these cases, for those who insist 
> to use the operator instead of some very fast bit-muggling if 
> they need a toggling function.

It is better that the library function takes care correctly of 
all cases than requiring all user of a function to insert 
boilerplate code to handle special cases that are well defined.

>
>>> To make this more prominent for the user, I would only allow 
>>> 8bit exponents anyway.
>>
>> I am the user in question and I am not a moron. Thanks a lot.
> I didn't say that. Don't lay words into my mouth.
>
>> This is such a trivial issue. This shouldn't be this hard.
> It's not hard. But there are a lot of cases where giving a 
> negative exponent is NOT intended, and maybe it is a better 
> idea to throw to indicate misuse instead of rounding away all 
> information by returning 0? (except for the three special cases 
> where I already agreed treating them correct would be a win).
>
> To summarize:
> If we need to stay with int ^^ int == int, I vote NOT to return 
> 0 for negative exponent and still throw, except for the three 
> special cases, where the correct result should be given.

Except for 0^^0 there is no reason to throw or crap out. 
int.max+1 also doesn't throw and it is also generally a probable 
bug in the user code.