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

[Timon Gehr]

On 17.12.19 14:39, 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?

Yes.

> Am I crazy?
> 

Probably not, but note that I am wasting hours of my finite life on what 
should be a trivial issue with a trivial fix, so I hope you do 
understand my slight frustration. This is not efficient.

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

pow(int,ubyte) works. pow(complex,complex) works.

> because an implausible input range for the 
> exponent is defined.

There are reasonable outputs for the entire range of each individual 
argument.

> I still think this should be fixed.
> ...

I will argue against this and we will both lose some more time, but feel 
free to open an enhancement request on bugzilla if you think it is worth it.

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

I don't insist on doing that. I only insist on the function producing 
correct outputs _when_ it is used. There is no reason to expect it not 
to work. Also, "very fast bit-muggling" often just does not matter in 
practice (especially because the compiler developers also know it), it 
is more typing and it is less readable especially if there is some 
analogous domain-specific notation.

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

I didn't do that. In the context of the thread it is however reasonable 
to interpret your statement as suggesting that I need hand-holding. This 
is further reinforced by your statement about bit-muggling. (There is a 
certain kind of smugness that is somewhat common with mediocre 
programmers, and your statements will resonate with the afflicted, even 
if you didn't intend them that way.)

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

I'd highly prefer it to consistently return 0 rather than kill my 
program without a stack trace. However, I agree that this case is 
slightly less clear-cut.

> (except for the three special cases where I already agreed treating them 
> correct would be a win).
> ...

(After I repeated my explanation for the third time.)