[sf-lug] Old Calculator Problems

[Michael Paoli]

Once upon a time, had an very good math teacher in
jr. high or high school at the time.  We were just
starting to use TI-30 calculators - they were relatively
new on the market, and notably, reasonably affordable
calculators.

So, various folks would notice, some calculations
wouldn't give precisely the correct answer.  Yes,
these were "8-digit" calculators ... they displayed
8 decimal digits.  But internally they used 11
decimal digits ... and would round the displayed
results to 8 decimal digits.

Anyway, one could do a calculation like:
2^3 and (sorry, I no longer have TI-30 at
my fingertips - nor easily found handy good
emulation of it) it would display a result
from 2^3 of something like (I don't remember
precisely what it did, but, something like
or with similar calculations)
2^3=7.9999998 ... rather than the expected 8.
Well, I forget how many functions, but the TI-30
had something like maybe 20 or so various functions.
But our math teacher went on to explain how it came up
with and showed the result it did.  And that also,
internally, the calculator didn't really implement
nearly so many functions, but rather a much smaller
subset of functions, and used some basic math laws
to convert from entered functions, to some more
fundamental functions it implemented.
E.g. even though the calculator had power and
root functions, and log base 10 and base 10 power
function, it didn't actually directly implement
any of those.  It instead just used it's natural log
and natural exponentiation functions ... along with
a bit of basic math laws.
So, e.g., if one entered something like:
2^3= and got 7.9999998
well, what the calculator was doing
internally, was instead:
e(3*l(2))
(where I use e() to show exponentiation of
natural log base e,
and l() for natural log (again, base e).
And if one instead instructed the calculator
to do e(3*l(2)), one would get precisely the
same answer from the calculator as when telling
it to do 2^3.  Also useful to point out, that
with the calculator's x^y function, neither x nor
y need be integers, hence another reason it didn't
simply do x*x*x, most notably as the exponent might
not be an integer.
So, e.g., if we do:
$ echo 'e(3*l(2))' | bc -l
7.99999999999999999982
$
We see we don't quite get 8.
Of course bc -l is defaulting to
bit more accuracy than a TI-30.
But if we want to get closer to
emulating a TI-30:
$ echo 'scale=10;e(3*l(2))' | bc -l
7.9999999985
$
... but alas, that results rounded to 8 significant
decimal digits would be 8.
However, internally, the TI-30 had more significant
digits.  E.g. could subtract 8 from the displayed 8
and get a result showing the (non-zero) difference.
That's also how I first memorized Pi to 11 (rounded)
digits ... I'd have the calculator give me Pi (one of
it's basic "functions" ... then I'd subtract from
that the 8 decimal digits that it displayed ...
so I'd then "know" Pi to 11 significant digits ...
at least with the TI-30's rounding anyway (last
digit was rounded up rather than a correct digit
of Pi).
"Of course" with bc(1), we can get more significant
digits if we want, e.g.:
$ echo 'scale=50;4*a(1)' | bc -l
3.14159265358979323846264338327950288419716939937508
$
And, relatively similarly, bc(1) implements fundamental
functions - it doesn't bother with those that can be simply
calculated from others using simple math laws.
So, e.g. it has no general exponentiation or base/root
function, likewise it doesn't have log base 10 or
exponentiation base 10 ... but it does have
exponentiation of natural base (e), and does
have natural log - again base e - as the others
can be calculated from those.  Likewise it has
sin, but cos or tan functions - as those can all
be calculated using sin and some basic arithmetic.

Some of the differences from the "precise" answer, at least
for many calculators, also have (slightly) to do with it,
at least typically, internally using base 2 (binary) for
many/most operations and numeric representation, and not
base 10.  Anyway, the differences between direct exact
mathematical formulas, and how the calculator actually
calculates, round-off/truncation losses of precision,
and differences in base, those all accumulate to some
bits of imprecision and not quite exact answers - at
least in many cases.  With digital, however, given
sufficient resources, one can always push for a
more accurate answer.  But, as for precise
mathematically correct answer?  Some
programs and software can do that - but your
basic typical calculator, and typical digital
calculation programs/utilities/libraries won't
do that - they'll generally just give you a
fairly precise decimal approximation - at
least notably if they have to deviate from
simple integer arithmetic or numbers that can
be represented as a single integer.

> From: "Sujit K M" <kmsujit at gmail.com>
> Subject: [sf-lug] Old Calculator Problems
> Date: Wed, 10 Aug 2016 21:04:45 +0530

> Hi All,
>
> Just inspired by the Shell Scripting sciences I got inspired by  
> something else.
>
> I find something strange with my calculator it calculates from
> the width of the decimal on my desktop.
>
> For Example
>           1.  6*2/3 = 4
>           2.  6*0.667 = 4.002
>           3.  6*0.6666666667 =   4.0000000002
>           4.  6*0.6666666666666667 = 4.
>
> Are there any standards for this. #4 should also lead to a value of
> 4.0000000000000002.
> Why is the calculator behaving strangely? There is no way in the world
> width of the decimal
> is affecting the result. Its a Desktop PC Calculator(Sounds Microsoft).
>
> What is the problem? I would love to dwell into the sciences that go
> into, might be an
> opensource calculator with source code ofcourse.