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

[Timon Gehr]

On 18.12.19 03:44, Timon Gehr wrote:
> On 18.12.19 03:30, Timon Gehr wrote:
>> On 18.12.19 03:14, Timon Gehr wrote:
>>>
>>> Perhaps what you mean to say is that the C++ standard is understood 
>>> to be so lax that it doesn't actually define the expected result of 
>>> pow for anything but the listed special cases, such that pedantically 
>>> speaking, pow could return NaN (or, usually, any other value) for all 
>>> other pairs of arguments (usually, without raising a domain error)?
>>
>> Reviewing this page, this does not appear to be the case either:
>> https://en.cppreference.com/w/cpp/numeric/fenv/FE_round
>>
>> So I guess I still don't understand why you think an implementation 
>> could return an arbitrary value.
> 
> The following simple test that would have been able to refute my 
> interpretation of the standard failed to do so:
> 
> ...

The following D code shows that Phobos's floating point pow is a worse 
implementation than the one in glibc++:

import std.math, std.stdio;
void main(){
     FloatingPointControl fpctrl;
     double x=328.78732,y=36.2;
     fpctrl.rounding = FloatingPointControl.roundDown;
     double r1=x^^y;
     fpctrl.rounding = FloatingPointControl.roundUp;
     double r2=x^^y;
     writeln(*cast(ulong*)&r1); // 5969924476430611442
     writeln(*cast(ulong*)&r2); // 5969924476430611444
}

With glibc++, the two values differ by a single ulp.