# to the nth power

[Ron Newman]

In article <4239 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard
A. O'Keefe) writes:
|> In article <1990Nov10.224939.23622 at dirtydog.ima.isc.com>,
karl at ima.isc.com (Karl Heuer) writes:

|> > An error of a single ulp is enough to cause
|> > (int)pow(2.0, 3.0) to return 7 instead of 8 (which it does, on
several current
|> > implementations).
|> 
|> Well, yes, but so what?  That's an incredibly stupid way to
calculate
|> integer powers in the first place.  What you want is ROUND TO
NEAREST,
|> not TRUNCATE TOWARDS ZERO. ...
|> 
|> Using pow() is just fine if you ROUND instead of TRUNCATING.
|> (Oh for the good old Algol 60 days...)
|> 
|> As a matter of genuine curiosity, just how useful is a general
integer
|> power function anyway?  On a 32-bit machine, you can compute 2**n
for
|> 0 <= n <= 30 only (might as well use a table), and for larger
numbers
|> the useful range of n is smaller.  (For 10**n, the range is 0 <= n <=
9.
|> Again, you would be better off with a table.)
|> 
|> I fully appreciate that integer powers are useful in languages like
Lisp
|> without artificial restrictions on integer size, but in __C__?

The problem isn't just that some implementations of pow(x,y) are 
inaccurate when x and y are BOTH integers.  They are also inaccurate 
when x isn't an integer but y is.  It's just as bad when

     pow(0.5, 3.0) != 0.125, or
     pow(1.25, 3.0) != 1.953125

It's acceptable for pow() to give inexact results when the exact result
is not representable as a double.  It's not acceptable to get an
inexact
result when an exact one is possible.   If the ANSI standard for pow() 
doesn't say this, then it should.

/Ron Newman