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