Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.

550. What should the return type ofpow(float,int) be?

Section: 29.7[c.math]Status:CD1Submitter: Howard HinnantOpened: 2006-01-12Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [c.math].

View all issues withCD1 status.

Discussion:

Assuming we adopt theCcompatibility package from C99 what should be the return type of thefollowing signature be:

?  pow(float, int);

C++03 says that the return type should befloat.TR1 and C90/99 say the return type should bedouble. This can putclients into a situation where C++03 provides answers that are not as highquality as C90/C99/TR1. For example:

#include <math.h>int main(){    float x = 2080703.375F;    double y = pow(x, 2);}

Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:

y = 4329326534736.390625

which is exactly right. While C++98/C++03 demands:

y = 4329326510080.

which is only approximately right.

I recommend that C++0X adopt the mixed mode arithmetic already adopted byFortran, C and TR1 and make the return type ofpow(float,int) bedouble.

[Kona (2007): Other functions that are affected by this issue includeldexp,scalbln, andscalbn. We also believe that there is a typo in26.7/10:float nexttoward(float, long double); [sic] should befloatnexttoward(float, float); Proposed Disposition: Review (the proposedresolution appears above, rather than below, the heading "Proposedresolution")]

[Howard, post Kona:]

Unfortunately I strongly disagree with a part of the resolutionfrom Kona. I am moving from New to Open instead of to Review because I do not believewe have consensus on the intent of the resolution.

This issue does not includeldexp,scalbln, andscalbn becausethe second integral parameter in each of these signatures (from C99) isnot ageneric parameter according to C99 7.22p2. The corresponding C++ overloads areintended (as far as I know) to correspond directly to C99's definition ofgeneric parameter.

For similar reasons, I do not believe that the secondlong double parameter ofnexttoward, nor the return type of this function, is in error. I believe thecorrect signature is:

float nexttoward(float, long double);

which is what both the C++0X working paper and C99 state (as far as I currently understand).

This is reallyonly aboutpow(float, int). And this is because C++98 took oneroute (withpow only) and C99 took another (with many math functions in<tgmath.h>.The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.

[Bellevue:]

This signature was not picked up from C99. Instead, if one typespow(2.0f,2), the promotion rules will invoke "double pow(double,double)", which generally gives special treatment for integralexponents, preserving full accuracy of the result. New proposedwording provided.

Proposed resolution:

Change 29.7[c.math] p10:

The added signatures are:

...float pow(float, int);...double pow(double, int);...long double pow(long double, int);