Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: Implementation of pow(3m) function
Keywords: math-library exponentiation C
Message-ID: <11143@alice.UUCP>
Date: 4 Aug 90 14:25:17 GMT
References: <1990Aug2.120706.25713@bnrgate.bnr.ca> <13474@smoke.BRL.MIL> <46584@brunix.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 27

In article <46584@brunix.UUCP>, gvr@cs.brown.edu (George V. Reilly) writes:

> There are many common special cases where calling pow is unwise:
> when y = 0.5, use sqrt instead; when y is a small positive or negative
> integer, just do the multiplications by hand; when y is of the form
> 1/k (i.e., you're trying to find the k-th root of x), use the
> Newton-Raphson method instead.

A lot depends on what you're trying to do.

Getting an accurate pow() function is very, very difficult.  Even if
your exp() and log() return results that are the most accurate they
can possibly be, I believe that evaluating exp(y*log(x)) for pow(x,y)
can lose up to 12 low-order bits of precision.

I have seen pow() functions that, in the interest of speed, check
for various special values of the second argument (0.5, integers,
and so on) and use fast algorithms for those cases.  If such an
implementation uses exp and log for the ordinary cases, it will
almost surely not be monotonic.  That is, it will be possible to
find positive x, y, and z such that y > z and pow(x,y) < pow(x,z).

I believe that if I were to set out to write a good pow() function
from scratch, it would take me at least several months.
-- 
				--Andrew Koenig
				  ark@europa.att.com