fin@norge.unet.umn.edu (Craig A. Finseth) (10/23/90)
This article describes an interesting *artifact*[1] of the mechanism use for computing COS and ACOS. It has been tested on an HP-48SX and TI-PROCALC (don't ask). It is *NOT* a bug report! Type the following on an HP-48SX: DEG 0 COS COS COS COS you should see (in the STD display mode): .999847741531 Repeated pressings of the COS key at this point will return the same number. All is well and good. I can well believe that, with 12-digit arithmetic, there is a "fixed" point at which COS(x) -> x. Now do: ACOS You will see: .99984774182 Obviously, the ACOS algorithm has a different fixed point if, indeed, it has one at all. The Solver reports a sign reversal for: 'ACOS(X)=X' at, oddly enough, .9998447741531. Again, this is not a bug report, just an observation. Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A. [1] Artifact: An unexpected property of a correct implementation.
ags@seaman.cc.purdue.edu (Dave Seaman) (10/25/90)
In article <2821@uc.msc.umn.edu> fin@norge.unet.umn.edu (Craig A. Finseth) writes: >This article describes an interesting *artifact*[1] of the mechanism >use for computing COS and ACOS. It has been tested on an HP-48SX and >TI-PROCALC (don't ask). It is *NOT* a bug report! It is not a property of HP calculators or of the "mechanism" used for computing COS and ACOS. It is merely a property of floating point arithmetic in general. The fixed point of COS (computed in degrees) and of ACOS (computed in degrees) is the same. The common value, to 20 places, is x0 = 0.99984774153108811295 which means that the HP48 computed the best 12-digit approximation, x1 = 0.999847741531 where the error x1-x0 is approximately -8.8 * 10^-14. Letting g(x) = 180/pi * arccos(x) we get the linear approximation g(x1) ~= g(x0) + (x1-x0)*g'(x0) where the g'(x0) term is approximately -3283.47, which explains why g(x1)-g(x0) is unexpectedly large. The linear approximation gives g(x1) ~= 0.999847741820 to twelve places, which agrees with the HP48 result to the very last digit. There is no way that any twelve-digit decimal-based machine could possibly give better results for this example than the HP48 does. -- Dave Seaman ags@seaman.cc.purdue.edu
fin@norge.unet.umn.edu (Craig A. Finseth) (10/25/90)
In article <15610@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes: >In article <2821@uc.msc.umn.edu> fin@norge.unet.umn.edu (Craig A. Finseth) >writes: >>This article describes an interesting *artifact*[1] of the mechanism >>use for computing COS and ACOS. It has been tested on an HP-48SX and >>TI-PROCALC (don't ask). It is *NOT* a bug report! > >It is not a property of HP calculators or of the "mechanism" used for >computing COS and ACOS. It is merely a property of floating point >arithmetic in general. ... I think that you missed the point. I know perfectly well about how fixed point arithmetic works and about fixed points of functions. That was the preface. The obvservation was that COS(x) had a fixed point but ACOS(x) did not. >Dave Seaman >ags@seaman.cc.purdue.edu Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (10/25/90)
In article <2830@uc.msc.umn.edu>, fin@norge.unet.umn.edu (Craig A. Finseth) writes: > The obvservation was that COS(x) had a fixed point but ACOS(x) did not. An intuitive explanation is that COS is pushing numbers closer together in the region of the fixed point. E.g., the cosines of two numbers in that vicinity of the fixed point will be closer together than the original numbers. So repeated applications of COS move closer to the fixed point; the representable real closest to the fixed point returns itself. ACOS spreads numbers out; the inverse cosines of two numbers in that vicinity will be farther apart. So ACOS magnifies the difference between the representable real closest to the fixed point and the fixed point. It is like the difference between a smooth peak and a smooth valley. Both have flat points where one could theoretically place a ball and have it remain at rest. But it's a lot harder on the peak than in the valley. -- edp
ags@seaman.cc.purdue.edu (Dave Seaman) (10/25/90)
In article <2830@uc.msc.umn.edu> fin@norge.unet.umn.edu (Craig A. Finseth) writes: >I think that you missed the point. I know perfectly well about how >fixed point arithmetic works and about fixed points of functions. >That was the preface. The obvservation was that COS(x) had a fixed >point but ACOS(x) did not. Actually, the observation was (quoting from 2821@uc.msc.umn.edu): >Obviously, the ACOS algorithm has a different fixed point if, indeed, >it has one at all. The Solver reports a sign reversal for: > > 'ACOS(X)=X' > >at, oddly enough, .9998447741531. The fact that you thought there might be a different fixed point, plus the fact that you seemed to be surprised at the apparent coincidence that the sign reversal occurred at precisely the right value, led me to believe that you might not understand the mathematical properties of your example. That is what I tried to explain. -- Dave Seaman ags@seaman.cc.purdue.edu
paulm@hpcvlx.cv.hp.com (Paul J. McClellan) (10/26/90)
If you plot the equation 'COS(X)=X' using the HP-28S in degree mode you will see that a mathematical solution is plausible. Indeed, one does exist. Applying ACOS to both sides of this equation, we obtain 'X=ACOS(X)', which has the same mathematical solution. Using the HP-28S solver, I obtain the following results in degree mode: 1. Solving 'COS(X)=X' for X with initial guess 1 => "Zero" .999847741531 2. Solving 'ACOS(X)=X' for X with initial guess 1 => "Sign Reversal" .999847741531 These computed results do, indeed, agree. In radian mode I obtain: 1. Solving 'COS(X)=X' for X with initial guess 1 => "Zero" .739085133215 2. Solving 'ACOS(X)=X' for X with initial guess 1 => "Zero" .739085133215 These computed results also agree. +--------------------------------------------------------------------+ | Paul J. McClellan | paulm@cv.hp.com | | Information Technology Operation | {backbone}!hplabs!hp-pcd!paulm | | Hewlett Packard Co. | (USA) (503) 750-2493 VOICE | | 1000 N.E. Circle Blvd. | (USA) (503) 750-4980 FAX | | Corvallis, OR 97330 | | +--------------------------------------------------------------------+ | All relevant disclaimers apply. | +--------------------------------------------------------------------+
jmorriso@ee.ubc.ca (John Paul Morrison) (10/26/90)
I _do_ think this is about floating point precision.
the function you strated with was
cos(pi/180*x)=x
then the inverse is
180/pi*acos(x)=x
BOTH of these have fixed points, since a fixed point is where f(x)=x.
However the first fixed point is stable. ie if the fixed point is perterbed,
it will converge come back to that point after some more iterations.
The second fixed point is UNstable, ie an error will be quickly amplified.
This iterative technique is called Picard's method (at least in some
books) for
finding roots. If you can write g(x)=o as f(x)=x, you can iteratively
find a root
of g(x). But if r is near the root of g(x), the series will converge if
|g'(r)| < 1.