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

[Timon Gehr]

On 17.12.19 13:03, Dominikus Dittes Scherkl wrote:
> On Monday, 16 December 2019 at 15:57:13 UTC, jmh530 wrote:
>> On Monday, 16 December 2019 at 15:49:35 UTC, Patrick Schluter wrote:
>>> [snip]
>>>
>>> Why can't that pow(int, int) function implement that workaround and 
>>> return 0 on all negative exponents and not crash otherwise?
> 
> I still don't understand

Please read the entire thread.

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

> I think

You are wrong.

> 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. The bug report is 
for an existing feature that does not work correctly.

> both working correct for any possible input, but of course the integer 
> version is likely to overflow even for relatively small exponents.

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.

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

> If you call it with something sensible, the exponent should fit 
> that, else the result will be some garbage anyway. Same with negative 
> exponents - rounding away any bit of information from the result is just 
> an offense. Why offer such nonsense? Anybody interested in using pow 
> with negative exponents cannot be interested in an interger result.
> ...

I really don't understand the source of those weird `pow`-related 
prejudices. You are the one who is spewing nonsense.

This is such a trivial issue. This shouldn't be this hard.