Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: # to the nth power
Message-ID: <4233@goanna.cs.rmit.oz.au>
Date: 10 Nov 90 09:44:58 GMT
References: <90305.005050CJH101@psuvm.psu.edu> <prk.657559483@pegasus> <1990Nov9.152921@lotus.lotus.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 43

In article <1990Nov9.152921@lotus.lotus.com>, rnewman@lotus.lotus.com (Ron Newman ) writes:
> In article <4200@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard
> A. O'Keefe) writes:
> |> pow() checks for integral exponents.
> 
> Unfortunately, many implementations of pow(), such as in Unix System V
> for PC's, don't produce acceptable results for integral exponents.
> You get aberrant results like pow(10.0,3.0) != 1000.0, or pow(3.0,2.0)
> != 9.0.

SVID release 2, vol 1, p 170:
        double pow(x, y)
        double x, y;
[so much for putting the type on the previous line being "standard"!]
                                         y
        The functions [sic] pow returns x.  If x is zero, y must be
	positive.  If x is negative, y must be an integer.
	The function pow returns 0 and sets errno to EDOM when x is 0
	and y is non-positive, or when x is negative and y is not an
	integer.  In these cases a message indicating DOMAIN error is
	printed on the standard error output.  When the correct value
	for pow would overfluw or underflow, pow returns +/- HUGE or 0
	respectively and sets errno to ERANGE.
    FUTURE DIRECTIONS
	The return value of pow will be negative HUGE_VAL when an
	illegal combination of input arguments is passed to pow.
	[HUGE_VAL is +infinity if you have it, +MAX_DOUBLE otherwise.]

This definition has now been superseded by the ANSI C standard, but I
think it was the definition which was relevant to UNIX PCs.  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.
The company I used to work for once got a bug report from a vendor that
we were porting our product to; it was my pleasure to track that bug
down to a mistake in that vendor's version of the UNIX V.2 math library.

So yes, you may have to work around mistakes in pow() just as you may have
to work around mistakes in printf() -- I've had to do that too -- but that
doesn't mean that pow() or printf() was not the appropriate function to try.

-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.