Path: utzoo!attcan!uunet!lotus!lotus!rnewman
From: rnewman@lotus.lotus.com (Ron Newman )
Newsgroups: comp.lang.c
Subject: Re: # to the nth power
Message-ID: <1990Nov12.171203@lotus.lotus.com>
Date: 12 Nov 90 22:12:03 GMT
References: <90305.005050CJH101@psuvm.psu.edu> <prk.657559483@pegasus> <1990Nov10.224939.23622@dirtydog.ima.isc.com> <4239@goanna.cs.rmit.oz.au>
Sender: news@lotus.com
Reply-To: rnewman@lotus.lotus.com (Ron Newman )
Organization: Lotus Development Corp.
Lines: 47

In article <4239@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard
A. O'Keefe) writes:
|> In article <1990Nov10.224939.23622@dirtydog.ima.isc.com>,
karl@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