issue 7006 - std.math.pow (integral, integral) crashes on negative exponents
Timon Gehr
timon.gehr at gmx.ch
Tue Dec 17 17:09:37 UTC 2019
On 17.12.19 17:48, Martin Tschierschke wrote:
> On Tuesday, 17 December 2019 at 14:02:53 UTC, Patrick Schluter wrote:
> [...]
>>> 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.
>>
>> Except for 0^^0 there is no reason to throw or crap out. int.max+1
>> also doesn't throw and it is also generally a probable bug in the user
>> code.
>
> But 0^^0 in general, is very often replaced by lim x-> 0 x^^x witch is 1.
> ...
0^^0 is 1 because there is one canonical function mapping the empty set
to itself. Also, if one really wants a justification involving calculus
look no further than Taylor series.
> The question is answered here:
>
> https://stackoverflow.com/questions/19955968/why-is-math-pow0-0-1
> ...
This is probably the most useful answer:
https://stackoverflow.com/a/20376146
> ...long story but may be this is the point:
>
> "as a general rule, native functions to any language should work as
> described in the language specification. Sometimes this includes
> explicitly "undefined behavior" where it's up to the implementer to
> determine what the result should be, however this is not a case of
> undefined behavior."
>
> If you look at pow in the cpp.reference language definition, you realize
> how 'complex' the pow issue becomes...
>
> https://en.cppreference.com/w/cpp/numeric/math/pow
This function does not handle integers separately. 0^^0=1 is completely
mundane.
More information about the Digitalmars-d
mailing list