# to the nth power
Ron Newman
rnewman at lotus.lotus.com
Tue Nov 13 09:12:03 AEST 1990
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
More information about the Comp.lang.c
mailing list