29 views

Skip to first unread message

Aug 31, 1996, 3:00:00 AM8/31/96

to

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-

Aug 31, 1996, 3:00:00 AM8/31/96

to

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

Sep 3, 1996, 3:00:00 AM9/3/96

to

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.

Sep 4, 1996, 3:00:00 AM9/4/96

to

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 )

Sep 5, 1996, 3:00:00 AM9/5/96

to jhme...@miu.edu

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

Sep 5, 1996, 3:00:00 AM9/5/96

to

<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

Sep 6, 1996, 3:00:00 AM9/6/96

to

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

Sep 6, 1996, 3:00:00 AM9/6/96

to

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.

Sep 16, 1996, 3:00:00 AM9/16/96

to

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.

^ ^

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu