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

[Dominikus Dittes Scherkl]

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!

>
>> 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.

>> 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.