Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lotus!lotus!rnewman
From: rnewman@lotus.lotus.com (Ron Newman )
Newsgroups: comp.lang.c
Subject: Re: # to the nth power
Message-ID: <1990Nov9.152921@lotus.lotus.com>
Date: 10 Nov 90 01:29:21 GMT
References: <90305.005050CJH101@psuvm.psu.edu> <prk.657559483@pegasus> <4200@goanna.cs.rmit.oz.au>
Sender: news@lotus.com
Reply-To: rnewman@lotus.lotus.com (Ron Newman )
Organization: Lotus Development Corp.
Lines: 35

In article <4200@goanna.cs.rmit.oz.au>, ok@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