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

[Timon Gehr]

On Tuesday, 17 December 2019 at 20:55:07 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 17 December 2019 at 20:35:33 UTC, Timon Gehr wrote:
>>> Besides, that is not what it said on the page.
>>
>> Yes, this is precisely what is says on the page.
>
> Er.. No.

It says implementations that support NaN may choose to return NaN 
instead of 1. If we agree, as I intended, to not consider 
implementations with no NaN support, how exactly is this not what 
it says on the page? (Please no more pointless elaborations on 
what common terms mean, ideally just tell me what, in your 
opinion, is a concise description of what results an 
implementation is _allowed_ to give me for std::pow(0.0,0.0) on 
x86. For instance, if I added a single special case for 
std::pow(0.0,0.0) to a standards-compliant C++17 implementation 
for x86-64 with floating-point support, which values could I 
return without breaking C++17 standard compliance?)

> As I said, it is an ISO standard, and thus exists to codify 
> existing practice. That means that  some representatives from 
> countries can block decisions.

(I'm aware.)

> So first the webpage say that you may get a domain error. Then 
> it refers to an IEC standard from 1989.
> ...

They don't say that C++ `std::pow` itself is supposed to satisfy 
the constraints of `pow` in that standard, and as far as I can 
tell it is either not the case, or that constraint was not in the 
floating point standard at the time, as this article states that 
C++ leaves the result unspecified:

https://en.wikipedia.org/wiki/Zero_to_the_power_of_zero#Programming_languages

If you think this is inaccurate, you should probably take the 
fight to whoever wrote that article, as this is where I 
double-checked my claim and the article has been linked in this 
thread before I made that claim, but it seems like it is right as 
it also says that the C99 standard was explicitly amended to 
require pow(0.0,0.0)==1.0.

> The may part is usually there to not make life difficult for 
> existing implementations. So the foundation is IEC, but to 
> bring all on board they probably put in openings that _MAY_ be 
> used.
>
> This is what you get from standardization. The purpose of ISO 
> standardization is not create something new and pretty, but to 
> reduce tendencies towards diverging ad hoc or proprietary 
> standards. It is basically there to support international 
> markets and fair competition... Not to create beautiful objects.
> ...

I didn't say that the result was _supposed_ to be beautiful, just 
that on face value it is ugly and funny. In any case, you will 
probably agree that it's not a place to draw inspiration from for 
the subject matter of this thread.

> The process isn't really suited for programming language 
> design, I think C++ is an outlier.

Indeed, however it is still somewhat common for very popular 
languages:
https://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard