# to the nth power

Ron Newman rnewman at lotus.lotus.com
Sat Nov 10 12:29:21 AEST 1990


In article <4200 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard
A. O'Keefe) writes:
|>.....  C's pow() function is precisely as capable as
|> Fortran's ** operator.  In particular,
|> 	#include <math.h>
|> 	...
|> 	x = pow(-1.0e6, (double)10);
|> will set x to 1.0e60.  pow() checks for integral exponents.

Unfortunately, many implementations of pow(), such as in Unix System V
for PC's, don't produce acceptable results for integral exponents.
You get aberrant results like pow(10.0,3.0) != 1000.0, or pow(3.0,2.0)
!= 9.0.

There's really no excuse for this; if both the arguments and the result
of a floating-point math function can be represented exactly, then the
function should give the correct, exact result.   When it doesn't, the
function has been implemented wrong, in one or both of two ways:

   a) The function was implemented in terms of e^x and ln(x), instead
      of using the floating-point hardware's native operations
(typically
      2^x and y*log2(x))

   b) The function was implemented in terms of intermediate functions
      that return double-precision (64-bit) values.  This led to loss
      of precision because the underlying arithmetic was done with
      extended-precision (80-bit) values.

In our System V products for PC's, we had to bypass the operating-system
vendors'  math libraries and reimplement pow() (and several other
functions) in 
raw 80x87 assembly code.

/Ron Newman



More information about the Comp.lang.c mailing list