The Microsoft pow
routine is notoriously bad. It is possible to return correct results for these and similar operands, as the macOS pow
demonstrates, but Microsoft either has not put in the engineering work to do this or has chosen not to change their pow
implementation. Even for small integer operands with mathematical results that are representable in floating-point, pow
may return results that are slightly larger or slightly smaller than the correct value. When returns a result smaller than the exact integer result, then converting it to an integer results in truncation to the next lower integer.
Computing pow
is difficult, and not all implementations do a good job. For floating-point functions, the best quality theoretically possible is correctly rounded. A correctly rounded routine returns the number representable in the floating-point format that is closest to the exact mathematical result, rounded in a direction governed by a chosen rounding rule. (The most commonly used rounding rule is to round to the nearest value, with ties toward the even low digit. Other rules include rounding toward +∞, toward ?∞, and toward zero.) It is very difficult to compute pow
with correct rounding, and no commercial or commonly used implementation I am aware of does so.
Nevertheless, it is possible to design pow
so that it returns the exact result whenever the exact result is representable in the floating-point format. As I recall, the current macOS
pow implementation does this. Thus, the program in the question, when compiled and executed with macOS tools, will produce the expected results. Microsoft’s pow
does not have this property, so computing pow(x, 3)
may return a value slightly less than x3, even when x3 is representable.
Even if one is using a high-quality pow
implementation, it is generally desirable not to use pow
with small integer powers for reasons of speed. Computing pow(x, 3)
is slower than computing x*x*x
.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…