Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!mucs!logitek!grep!frank
From: frank@grep.co.uk (Frank Wales)
Newsgroups: comp.sys.handhelds
Subject: Re: How accurate is the 48??
Message-ID: <1991May22.152552.11251@grep.co.uk>
Date: 22 May 91 15:25:52 GMT
References: <7174@acorn.co.uk>
Reply-To: frank@grep.co.uk (Frank Wales)
Organization: Grep Limited, LEEDS, UK
Lines: 67

In article <7174@acorn.co.uk> asmith@acorn.co.uk (Andy Smith) writes:
>There is no doubt that the 28S and the 48SX are brilliant calculators, but
>one thing still puzzles me. Certainly with the 28S, although much better
>than most calculators (3/3=1, 2/3*3=1) it is still not "accurate" due to the
>limitations of how it stores numbers. 1/3*3 still gives 0.999999999. Does
>the 48 still suffer from this limitation?

All computers "suffer" from some version of this.  There are infinitely
many numbers that cannot be represented on machines with finite precision
arithmetic; that's why examples are so easy to find.  For example, 0.1 
is an infinitely-recurring fraction in binary, and uses of it exhibits
the same kind of problem you mention above.  Choosing the number of digits
to use is a classic engineering trade-off: accuracy v { cost speed space }.

N-bit binary floating point has the unfortunate property of sometimes
being unable to store exactly what the User entered (unless the User works in
binary too).  Modern calculators work directly in decimal rather than
binary to eliminate the noise introduced by the interbase conversions.  This
also helps enhance the User's confidence in the machine.

>A calculator that I wrote for the Archimedes uses 64 bit Floating point, but
>I cheat and round numbers up or down on the last digit of the calculation.

Why do you do consider this "cheating"?

>Could a similar idea not be used on the 48? 

The 48 performs calculations to at least 15 decimal digits of accuracy
internally, rounding results to 12 (some complex calculations use more
precision for greater reliability).  The example you cite above is
a particular case of a general problem, and HP have taken great care,
over almost 20 years, to ensure that their calculators have answers which
are both accurate (within the limitations of their precision) and
repeatable.  This latter criterion is more noticeable on HP machines
than on those of the competition, and is one reason why HP calculators
do *not* use guard digits except internally.  The effect of this is visible
in a calculation like root(2).  Perform this on some calculator, write down
the result visible in the display to the greatest precision the machine
displays, then subtract that written number from the original result.
If the answer isn't 0, the machine is hiding something from you.

Appreciating that serious mathemetical work sometimes needs to distinguish
3.14159265359, the closest 12-digit version of pi, from pi itself is the
reason why pi (and e) are treated specially by the 28 and 48.  This is
especially true after a dozen functions have been applied to the number;
sometimes its origin has an effect on the meaning of the calculation
(preserving the origin of all numbers in the machine is a potentially
useful but seriously unwieldy proposition for a calculator).

>Could numbers tending to an integer be rounded up or down on the 16th or 
>so decimal place if that number were a 9 or a 1 respectively??

I'm not sure what you mean here by "tending to an integer."  If an integer
result is expected, provide one.  Otherwise don't, since the calculator
cannot read the mind of the User and guess than an integer is what would
be the "right" answer.  Sometimes, 1.00000000001 *is* the right answer.  

These "problems" come about because the machine is attempting to represent
all possible numbers within its dynamic range using only edited highlights
of the number line.  No matter which highlights it uses, (i.e., which base,
and how far apart), it still cannot be truly "accurate" for all but a tiny
fraction of the possible numbers it could be called upon to represent.

It's all a part of the magic of making the discrete look continuous.  :-)
--
Frank Wales, Grep Limited,             [frank@grep.co.uk<->uunet!grep!frank]
Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303