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

Dominikus Dittes Scherkl dominikus.scherkl at continental-corporation.com
Tue Dec 17 12:03:12 UTC 2019


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 why anybody want a function with 
signature

int pow(int, int)

I think there are only two interesting cases:

int pow(int, ubyte)

and

complex pow(complex, complex)

both working correct for any possible input, but of course the 
integer version is likely to overflow even for relatively small 
exponents. To make this more prominent for the user, I would only 
allow 8bit exponents anyway. 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.

maybe (for performance reasons?)

real pow(real, real)

would also be of interest, but there are (strange) constraints to 
when the result is real, so I cannot really recommend this. In 
fact for an negative integral exponent n there are n solutions of 
which only one is real (or two if n is even).
So the signature would better be

real pow(real x, real e) in(e>=0)

But I would always prefer the two cases without constraints.



More information about the Digitalmars-d mailing list