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