Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!ima!dirtydog!karl
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: # to the nth power
Message-ID: <1990Nov10.224939.23622@dirtydog.ima.isc.com>
Date: 10 Nov 90 22:49:39 GMT
References: <90305.005050CJH101@psuvm.psu.edu> <prk.657559483@pegasus> <1990Nov9.152921@lotus.lotus.com> <4233@goanna.cs.rmit.oz.au>
Sender: news@dirtydog.ima.isc.com (NEWS ADMIN)
Reply-To: karl@ima.isc.com (Karl Heuer)
Organization: Interactive Systems
Lines: 21

In article <4233@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1990Nov9.152921@lotus.lotus.com>, rnewman@lotus.lotus.com (Ron Newman ) writes:
>> Unfortunately, many implementations of pow(), such as in Unix System V
>> for PC's, don't produce acceptable results for integral exponents.
>
>SVID release 2, vol 1, p 170: [Specs for pow().]  If the answer was
>significantly in error (compared with the code in Cody & Waite, say) it would
>have been appropriate to complain to the vendor.

How much is "significantly"?  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).  So unless the standards bodies (*not* the individual
vendors) are willing to guarantee exactness for this function, using pow() is
an unportable solution to the problem of integer-to-integer exponentiation.

(It's still possible to use
	#define ipow(i,j) ((int)(pow((double)i, (double)j)+0.5))
for positive numbers, and a more complicated adjustment to handle negatives as
well, but now it's more work than writing an ipow() function from scratch.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint