A puzzle
DNHART
As a new HP48GX owner, here's a good one (which you may be aware of).
Remember the Pentium bug last year, and the formula used to detect it?
Well, just for kicks, I ran the formula on the '48. You may recall it is
as follows:
4195835((4195835/3145727)*3145727)
It shoud return zero, since it essentially amounts to subtracting a number
from itself (with a buggy Pentium chip, it returns a bogus 256). A most
interesting answer of -.00001 turns up on the HP48 (and on a small TI36X
that I also have). A little Casio that our secretary uses does return zero
after running the formula. The formula was designed to run on a
spreadsheet, but that shouldn't make any difference, I wouldn't think.
I would be most interested in a good "answer" to this puzzle -- I'm sure
there's nothing buggy about the '48 . . . Like I mentioned, I'm a new user
and am not up to speed yet on the HP48.
-0- Dave Hart -0-
Richard Paschal
DNHART <dnh...@aol.com> wrote:
: 4195835((4195835/3145727)*3145727)
: It shoud return zero, since it essentially amounts to subtracting a number
: from itself (with a buggy Pentium chip, it returns a bogus 256). A most
: interesting answer of -.00001 turns up on the HP48 (and on a small TI36X
: that I also have). A little Casio that our secretary uses does return zero
: after running the formula. The formula was designed to run on a
: spreadsheet, but that shouldn't make any difference, I wouldn't think.
Shouldn't that be
4195835-((4195835/3145727)*3145727) ?
--
---------------------
rpas...@primenet.com
Steve Atwell
On Mon, 02 Sep 96 20:50:00 GMT, pa...@televault.com (Paul Pollack)
wrote:
>(I'm assuming you meant
>4195835 -((4195835/3145727)*3145727))
>
>My suspicion is that this is due to roundoff error. When the calculator
>computes 4195835/3145727 it loses some digits of accuracy; when it
>multiplies the number by 3145727 it compounds the error and you're left
>with a number slightly off from the original. Subtracting this
>from the original obviously produces some remainder.
>
>Virtually any handheld calculator will produce this; the TI-85 gives
>1e-7. The TI-92 gives the answer of 0 in exact mode (for obvious reasons),
>but also 1e-7 when evaluating the expression "approximately."
What I find odd is when I tried this on all three of my calculators
(HP48GX, TI-35x, and Casio fx-7700GB) the HP and the TI both gave
-.00001, while the Casio gave exactly 0. The Casio, I might add, does
internal calculation with 10 significant figures.
John H Meyers
On Mon, 02 Sep 96 20:50:00 GMT, pa...@televault.com (Paul Pollack) wrote:
> Re: 4195835 -((4195835/3145727)*3145727)) [ a test bad Pentiums fail ]
>
> My suspicion is that [non-zero result] is due to roundoff error [...]
> Virtually any handheld calculator will produce this; the TI-85 gives
> 1e-7. The TI-92 gives the answer of 0 in exact mode (for obvious reasons),
> but also 1e-7 when evaluating the expression "approximately."
In article <322c9bc2...@news.iaonline.com>,
sat...@iaonline.com (Steve Atwell) appended:
> What I find odd is when I tried this on all three of my calculators
> (HP48GX, TI-35x, and Casio fx-7700GB) the HP and the TI both gave
> -.00001, while the Casio gave exactly 0. The Casio, I might add, does
> internal calculation with 10 significant figures.
FUDGE!!!
Has anyone ever heard of a student adjusting the readings of an experiment
to produce the exact "right" answer, with a degree of accuracy just too good
to be true? Okay, it's about time we exposed the "Casio Computer Company"s
"fudging" of phoney-baloney "exact" results which don't exist!
Preface: My Casio experience goes from the very first scientific models
Casio ever produced, up to the fx-6300G (modest little grapher), all of
which behave as described below; post something if you know of any newer
or other models which behave differently.
To begin with, all HP handheld calculators since the very first HP35 (1972?)
have *rounded* every calculated value to the full precision of the registers
used for internally storing numbers (originally 10 digits, currently 12),
and have always displayed all digits of this full internal register width.
Every other calculator I have ever used (including all Casio's) *truncate*
every computed value to the number of digits in the internal storage
registers (11-12 digits in my various non-ancient scientific Casio's),
and then display the *truncated* internal result, after *rounding* that
value to a *smaller* number of digits (commonly 10) in the *display* only.
With HP's system, internal roundoff, which may be thought of as almost
a "random" perturbation of a hypothetical exact result, may accumulate
in a particular direction (either way), or may happen to end up with
even an "exact' result on occasion.
For example: take any 10-digit or 12-digit HP calculator, display the numeric
value of Pi, take repeated natural logarithms (LN) until approximately
-2.00123... appears, then repeated natural antilogarithms (e^x) until
approximately 3.14159... re-appears; the value you now get is exactly
the same value you started with!
Okay, pick up your Casio, start with its numeric value of Pi, and do the
same. When 3.14159... re-appears, it may (on 12-digit internal precision
calcs) look like the original value; however, just subtract Pi from it,
and you will see that you now have a small negative value (-2E-11 on my
fx-6300G), showing that repeated *truncation* has inevitably and
inexorably caused successive results to become *lower* -- always
in the same direction (see why *rounding* is better?)
A simpler illustration: Start with Pi (numeric), perform four square roots,
then four squarings, then subtract Pi. On a 10-digit HP, the result is
zero; on a 12-digit HP, the result is 1.9E-10, on a 12-digit Casio,
the result is -5E-10; once again, the Casio error is greater, and
every operation's truncation drives the answer's value definitely lower,
rather than the more generally accurate "random-walk" behavior of true
rounding (especially the "unbiased rounding" practiced in current HP's).
If you repeat square-root -> square (or almost any inverse function pair)
on an HP, the result quickly stabilizes to a pair of perpetually repeating
values, while a truncating calculator keeps "sailing off" in one direction
(except in some cases where complementary errors tend to cancel each other).
Of course, taking reciprocals of (or dividing by) truncated values will
cause errors in the opposite direction; however, in the formula at the
beginning of this article, after dividing one *exact* integer by another
*exact* integer, you then *multiply* the truncated result by another
*exact* value; therefore, YOU CAN NOT POSSIBLY OBTAIN THE EXACT
ORIGINAL RESULT ON A "TRUNCATING" CALCULATOR and get ZERO as the
final "difference" -- except on a "fudging" Casio calculator!
Now, let's investigate how Casio "fudges" its results:
A caution re fx-6300G and similar models: Do not continue a previous
calculation by using the previous *displayed* result, but always use
the "Ans" key to retrieve a previous answer (from the previous EXE) to as
much precision as was internally stored (ignore if you have no such keys).
First, you need to determine how many digits are kept in your Casio's
internal registers: Perform 80/9 - 8.88888, count how many digits
appear in the result (note the truncation, ending in 888, rather
than rounding, which would end in 889), and add six (this being the
number of leading answer digits we "subtracted out" from the answer).
If your Casio keeps 12 internal result digits, then the next exercise
to try is 123456789 + .008 - 123456789; if your Casio keeps 11 internal
result digits, then instead do 12345678 + .008 - 12345678
(if the internal registers have any other number of digits, the idea is
for the sum to use exactly as many digits as the registers contain).
Okay, big deal -- you got the answer .008 (8E-3) -- what did you expect?
Now substitute .007 for .008 and try again.
Hey! What happened? This time you got ZERO -- exactly!
Trying .006 thru .001, you continue to get ZERO!
Now try .999 thru .993 -- this time you get *exactly* 1
Finally, try .992 -- back to normal, you get .992 again.
Have you figured out what's up?
Here's the scoop: Every time this type of Casio calculates a numeric result,
it looks at the last three digits of the internal "mantissa" (the significant
digits of the truncated result); if these digits are anywhere in the range
001 thru 007, your Casio just lops off these digits, presuming that the
"correct" result *should* have ended with 000; similarly, if the last
three mantissa digits of the truncated result are in the range 993-999,
your helpful FUDGING Casio "fixes up" that result for you by
ROUNDING IT UP until its last three digits are 000 !!!
Now, some of the time, let's say when the problem is really about integers
(as was the case in the "Pentium error test" with which we began),
this helpful fudging will produce miraculously exact answers where
other "stupid" calculators may get some round-off (or "truncate-off")
errors (correctable via RND on the HP48 when you know that the result
is supposed to be an integer). Thus, almost any square root of an integer
can be squared on a Casio to produce the *exact* original integer -- a
feat which leaves other calculators bedazzled! This same fudge helps
Casio's to get integer answers when raising an integer to an integer
power via x^y (of course your HP manages this also, but via its "honest"
very accurate internal algorithm, rather than needing internal "cheating").
Even when the Casio sometimes fails, its "display round-off" (on 12-digit
calcs) sometimes mercifully hides the internal register's incorrect value.
Other times, however, internal mantissas ending with 001-007 or 993-999
should be left alone! However, your Casio scientific calculator has no
"brains" to know when to stop fudging -- it ALWAYS fudges every single
intermediate and final answer, sometimes making it more inaccurate than it
would have been if it had been a simple-minded "honest" truncating calculator;
thus, the price you pay for the internal "cheating" of the Casio is the
random wrongly-fudged answer that is equally often produced in the long run.
For example, if your Casio (slightly out of date, I guess) has 11-digit
internal mantissas, then square root of 380018 becomes *exactly* 616.456
whereas the correctly rounded 10-digit result should be 616.4560001;
likewise, the square of 616.456 becomes *exactly* 380018, whereas
the correctly rounded 10-digit result should be 380017.9999
Another cute bug in all the "11-digit" Casio's I've had which do
"base-conversion" and hexadecimal arithmetic is revealed by dividing
hex 7F777777 by 2; the correct result should be 3FBBBBBB, but these
11-digit Casio's all manage to get 3FBBBBBC instead!
How came this to pass? Well, unlike all HP's which deal with binary
integers, these Casio's do *not* have any separate data type or even
a different internal representation for binary integers. Casio's simply
store all numbers as *decimal*floating-point* values all the time!
When you are in a "binary" mode, these are simply *displayed*
in binary form, and when you type binary/octal/hex digits,
these are entered directly into the display and then converted
to a floating-point internal number afterwards (this scheme
complicates bit-wise logical operations, but who cares).
Guess what? The ever-present Casio internal *fudger* keeps right on
fudging (like the proverbial Timex), and when the last three mantissa
digits of the result of a *floating*point* division are 993 or greater,
the brainless Casio rounds up the answer and delivers a *rounded* answer
even for a *binary* integer division which is supposed to be *truncated*
(the calc always finally takes the integer part of binary results, but
it's too late -- "fudge" rounding-up has already occurred!)
On the fx-6300G and other "12-digit" (internal register) models, I have
not found an example of this problem, and indeed there may not exist any,
even though the internal fudger is ready and willing to try. Thus,
Casio engineers may never have fixed this bug, but by virtue of expanding
the internal registers by one more digit, it may have just gone away by itself.
Now that I've blasted away at Casio's for dramatic effect, I should
temper my exaggeratedly "slanted" review by explaining why, being an
HP fan since 1972, I have had so many Casio's!
Aside from HP, which is way off the top of the scale in quality and
engineering and human-factors design, Casio strikes me as having
consistently been the next most creative and innovative company; even
their keyboards were once clearly designed by masters of traditional Japanese
art (old scientifics had keys all the same actual size, but the faceplate
shading made the number keys look much bigger than scientific function keys);
more recent 4-function cheapies have the clearest displays & best keyboards.
The artistic elements are not as good as they once were, but for cheaper
"second" knock-abouts, Casio's are still fine with me. They also generally
keep on working reliably forever (so do Sharp's). Once in a while, Casio
engineers even do something practically impossible, like the SL-800 "film"
"credit-card" calculator that is actually as thin as a real credit-card
(yes it is!) -- probably carbon-fiber body, adhesive front & back film
that never "peels away", heaven knows where the "chip" is! Yes, mine's
still in my wallet and working perfectly after perhaps 15 years.
A similar feat was done with one scientific model (shirt-pocket size,
but extremely thin), which was also sold under Radio Shack brand name.
That's all for now, but remind me someday to come back to these
other topics:
o HP's 25-digit wide floating add/subtract, e.g.:
1E24 - 500000000000 = 1E24
1E24 - 500000000001 = 9.99999999999E23
Note that the difference between these cases is 1E0 out of 1E24 !!
(subtract different-magnitude values on any other brand, and compare).
o Casio's "jump-discontinuity" and inaccuracy in Hyperbolic functions
( discontinuity near X = .01/ln(10) , inaccurate near X = .005 ).
o Why some 4-function "truncating" Casio's get sqrt(24.999999)=4.9999999
(it's actually 4.9999998999999989999999799999995, rounded up slightly),
while others get 4.9999998 (normal truncation).
o TI's several-years run of calc's with incorrect multiplication! E.g.:
1.9999999 * 4.9999999 - 9.9999993 should be zero, but it wasn't always.
Particularly bad w/ 8-digit-display calcs, like "TI Programmer," but
also evident in TI-50, TI-30/35[only very old ones], old financial (BA-x?).
This bug also messed up all other functions that depend on multiplication.
Hint: the whole multiplication algorithm was fundamentally wrong!
o TI's long run of world's cheapest (& worst-corroding) failing keyboards
(all the latter-year 8x5 LED and subsequent early LCD keyboards, including
the otherwise excellent "TI-Converter" for Imperial/US <-> Metric units).
It is for good reason that HP has been dubbed "the Rolls-Royce of Calculators"
(and other equipment); okay, what should we call those other brands? :)
-----------------------------------------------------------
With best wishes from: John H Meyers ( jhme...@mum.edu )
Mwilson
John H Meyers wrote:
Just a quick for what its worth: the Casio fx-7000G performs as an Hp
when it comes to rounding. The only test you mentioned that it "fudged"
was the squaring and square rooting of Pi. It did return a 9 as the
last digit of 80/9, and does not round at .7 as your other models do.
Later,
Mark Wilson
Mark S Dayton
<snip>
:
: My suspicion is that this is due to roundoff error. When the calculator
: computes 4195835/3145727 it loses some digits of accuracy; when it
: multiplies the number by 3145727 it compounds the error and you're left
: with a number slightly off from the original. Subtracting this
: from the original obviously produces some remainder.
<snip>
I tried this equation using ALG48 and got the same results. Perhaps someone can explain why this program does this when it is supposed to do exact calculations with unlimited precision integers.
Mark D at Lock-Mart
Mika Heiskanen
day...@pogo.den.mmc.com (Mark S Dayton) writes:
> I tried this equation using ALG48 and got the same results. Perhaps someone
> can explain why this program does this when it is supposed to do exact
> calculations with unlimited precision integers.
Equation: '4195835-(4195835/3145727)*3145727'
EVAL ==> -.00001
RSIM ==> 0
ASIM ==> 0
FCTR ==> 0
RAT-> ==> 0 1
With flag 5 set for automatic simplification:
0 AADD ==> 0
0 ASUB ==> 0
1 AMUL ==> 0
1 ADIV ==> 0
1 APOW ==> 0
AINV ==> "Infinite Result" error
ANEG ==> '-(4195835...)' Humph, I don't remember if this
was ever discussed.
It seems like I can't offer any explanation.
--
---
--> Mika Heiskanen mhei...@gamma.hut.fi http://www.hut.fi/~mheiskan
John H Meyers
In article <50mpn8$6...@tel.den.mmc.com>,
day...@pogo.den.mmc.com (Mark S Dayton) writes:
>: My suspicion is that this is due to roundoff error. When the calculator
>: computes 4195835/3145727 it loses some digits of accuracy [...]
> I tried this equation using ALG48 and got the same results.
> explain why this program does this when it is supposed to do
> exact calculations with unlimited precision integers.
ALG48 does use unlimited-precision *integers*, but this is not the
same as unlimited-precision *decimals* (the latter is unachieveable,
because most decimal expansions are infinitely long).
You could expand the initial numerator by appending as many zeros as
you like, giving as much final accuracy as you like. You could also
maintain "rational" expressions involving finite integers to retain
"exact" accuracy when performing basic arithmetic.
Marco Pastrello
On 5 Sep 1996 14:56:40 GMT, day...@pogo.den.mmc.com (Mark S Dayton)
wrote:
>: My suspicion is that this is due to roundoff error. When the calculator
>: computes 4195835/3145727 it loses some digits of accuracy; when it
>: multiplies the number by 3145727 it compounds the error and you're left
>: with a number slightly off from the original. Subtracting this
>: from the original obviously produces some remainder.
I think so.
>I tried this equation using ALG48 and got the same results.
>Perhaps someone can explain why this program does this when it is
>supposed to do exact calculations with unlimited precision integers.
It *does* exact calculation with unlimited precision *integers*.
But when you do 4195835/3145727 you have to deal with reals.
^ ^