Apple's Calculator vs. decimal places

I just came across this on slashdot:
<http://www.pldesignline.com/howto/showArticle.jhtml;?articleID=175801189>
The "mother of all rounding algorithms discussions":

"In fact, the mind soon boggles at the variety and intricacies of the
rounding algorithms that may be used for different applications.

For example, we have round-up, round-down, round-toward-nearest, arithmetic
rounding, round-half-up, round-half-down, round-half-even, round-half-odd,
round-toward-zero, round-away-from-zero, round-ceiling, round-floor,
truncation (chopping), round-alternate, and round-random (stochastic
rounding), to name but a few. ..."

"But, nothing daunted, we are going to rip the veils asunder and discover
more about rounding than most of us ever wanted to know. We will commence
by introducing a smorgasbord of basic concepts...."

--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

> On Jan 6, 2006, at 9:52 AM, Kat Nagel wrote: > Um...no, I don't think it's a bug.  It's sound mathematical practice. > The solution to a subtraction problem has the precision of the least > precise number in the equation, not the most precise number. The calculator might be doing what is scientifically correct to do if it did it consistently. For example, 10.5 - 105 gives me -95 when scientifically it should give me -94.5. Both entries are 3 significant digits, but the answer is only two significant digits. Also, you get different answers depending upon the order. 10.5 + 6 gives you 17 while 6 + 10.5 gives you 16.5. If you have the paper tape showing, pressing "Recalculate" will always give you the correct answer. ======================================= Well, I've wrestled with reality for 35 years, doctor, and I'm happy to state I finally won out over it." -- Elwood P. Dowd  ======================================= David Weintraub davidweintraubworld.net davidweintraub.name

--On January 6, 2006 6:52:01 AM -0800 Kat Nagel <katnagelmac.com> wrote:

> Um...no, I don't think it's a bug. It's sound mathematical practice.
> The solution to a subtraction problem has the precision of the least
> precise number in the equation, not the most precise number.

In any series of operations the practice is to carry each operation out to
highest precision. Then after the last step set the precision. If you set
the precision at each step of the process you will accumulate errors at
each step, leading to a result that has the correct precision but is
totally inaccurate (accuracy and precision are separate things). If the
number of operations is high then the amount of error can be significant.

A calculator can't know if you're performing a one step operation or
continuing a series of operations. As such a calculator should use and
display the highest precision number it can.

On 06 Jan 2006, at 07:52 , Kat Nagel wrote:
> Um...no, I don't think it's a bug. It's sound mathematical practice.
> The solution to a subtraction problem has the precision of the least
> precise number in the equation, not the most precise number.

Yep. I would have LOVED this feature when I was in High School, as
it would have saved my bacon on more than one occasion. It is
especially appropriate to have this in the RPN portion of the maths.

Simply, when doing ANY calculation the result cannot have more
significant digits that the least significant operand.

13 + 2.1567 = 15
13.0 + 2.1567 = 15.2
13.00 + 2.1567 = 15.16
1.79 * 2 = 4
1.79 * 2.0 = 3.6
1.79 * 2.00 = 3.58

(3.58 * 7.19) / 3 = 9
(3.58 * 7.19) / 3.00 = 8.57 (and no, not 8.580 which a normal
calculator will give you)


Very useful to have a calculator that understands this.


--
"Hi Dad! It's 3am, do you know where I am?"

At 11:04 PM -0500 2006/01/07, David Weintraub wrote:
>The calculator might be doing what is scientifically correct to do
>if it did it consistently. For example, 10.5 - 105 gives me -95 when
>scientifically it should give me -94.5. Both entries are 3
>significant digits, but the answer is only two significant digits.

Ick. You're right.


>Also, you get different answers depending upon the order. 10.5 + 6
>gives you 17 while 6 + 10.5 gives you 16.5.

<sigh> Double ick.


>If you have the paper tape showing, pressing "Recalculate" will
>always give you the correct answer.

That's interesting. So, the correct information is actually there,
but it isn't displayed until you insist? Weird.

--
K
Kat Nagel, MasterWork Consulting
http://www.masterworkconsulting.com

585.820.4045
katnagelmasterworkconsulting.com

.

On 1/9/06 at 10:03 AM, gkremegmail.com (Google Kreme) wrote:

>(3.58 * 7.19) / 3.00 = 8.57 (and no, not 8.580 which a normal
>calculator will give you)

I don't understand why you would expect 8.57 instead of 8.58. If I do this computation with exact arithmetic i.e., (387/100 * 719/100)/3 I get 858/100 + 2/30000. That is clearly closer to 8.58 than 8.57

On 09 Jan 2006, at 23:18 , Bill Rowe wrote:

> On 1/9/06 at 10:03 AM, gkremegmail.com (Google Kreme) wrote:
>
>> (3.58 * 7.19) / 3.00 = 8.57 (and no, not 8.580 which a normal
>> calculator will give you)
>
> I don't understand why you would expect 8.57 instead of 8.58.

Because in my High School Calculus class 8.57 would be correct and
8.58 would be -1.

> If I do this computation with exact arithmetic i.e., (387/100 *
> 719/100)/3 I get 858/100 + 2/30000.

2/30000 is adding precision.

> That is clearly closer to 8.58 than 8.57

3.58 * 7.19 = 25.7
25.7 / 3.00 = 8.57

The principal is that you can't ADD precision at any step. Some
people consider this to be "adding errors" but in fact it is
maintaining the integrity of the math.

However, we've strayed far-afield, since it's become obvious that the
behavior in Calculator is in fact buggy.

--
My little brother got his arm stuck in the microwave. So my mom had
to take him to the hospital. My grandma dropped acid this morning,
and she freaked out. She hijacked a busload of penguins. So it's sort
of a family crisis. Bye!

On 1/10/06 at 11:24 AM, gkremegmail.com (Google Kreme) wrote:
>3.58 * 7.19 = 25.7
>25.7 / 3.00 = 8.57
>
>The principal is that you can't ADD precision at any step. Some
>people consider this to be "adding errors" but in fact it is
>maintaining the integrity of the math.

OK. Now I at least understand why you expected 8.57 instead of 8.58. But I would consider this a bug since I would not expect a bug free calculator to keep the precision of intermediate computations at the minimum precision of the original numbers. Instead, I would expect any rounding to occur only after the final computation which would cause this particular computation result to be 8.58.

In any case I do agree the issues raised about Apple's calculator should be considered bugs.

>Posted by: Lewis Butler Date: Jan 10, 2006.
>
>3.58 * 7.19 = 25.7
>25.7 / 3.00 = 8.57
>
>The principal is that you can't ADD precision at any step.

I just can't ignore this one. The real problem is that you can LOSE precision at any step, as done in the above multiplication.

The standard rounding rule that keeps as many significant digits as there are in the least accurate number when multiplying/dividing is only a *rule of thumb*. You sometimes need an extra significant digit. In fact, Mulliss & Lee estimate that the rule is in error 62% of the time for multiplication! More often than not, the standard rule loses precision. This is one of those many times.

<http://www.angelfire.com/oh/cmulliss/>
<http://mathforum.org/library/drmath/view/58335.html>

The correct answer to the first equation in the above example can be obtained by evaluating the multiplication longhand. An X is used to represent the unknown digit in each factor and to propagate it into the result. The following should be viewed in a monospaced font such as Courier.

           3.5 8 X
        x 7.1 9 X
   ---------------
           X X X X
       3 2 2 2 X
       3 5 8 X
   2 5 0 6 X
   ---------------
   2 5.7 4 0 2
   2 5.7 4 X X X X (4 significant digits in result !)

We then have

3.58 * 7.19 = 25.74
25.74 / 3.00 = 8.58

There is an alternate rounding rule that proposes using one more significant digit than indicated by the standard rule. This is about as successful as the standard rule for division but significantly more accurate for multiplication. In both cases it always preserves precision. See the first link above for details.

On Jan 13, 2006, at 8:29 AM, Mike Craymer wrote:
> The correct answer to the first equation in the above example can
> be obtained by evaluating the multiplication longhand.

The slide rule was so much easier for this multiplication stuff. One
also became much more adept at knowing when an answer didn't make
sense than the calculator-addicted folks of today are.

At a JPL meeting to justify a second IBM 704:
A: We need about xxx hours for calculation X on project Y.
B: That sounds about right...but when we did that calculation for
the Wac-Corporal project, I did it in a half hour on my slide rule.

[Note: B was a sort of answer verifier for many years. You create a
one-off calculation, run it, describe the problem and the calculated
answer to B. If, as often happened, B said "Hmmm...that seems about
10% high" you went back and found your error--which was almost always
there.]

Mother knew B quite well (and went through the answer-verifiying bit
with him on several computer programs). I only met him a few times.

   --John

> On 09-Jan-2006 David Weintraub wrote;
>
> For example, 10.5 - 105 gives me -95 when scientifically it
> should give me -94.5. Both entries are 3 significant digits, but the
> answer is only two significant digits.

I think that in this discussion we should state "significant decimal
places". Digits to the left of the decimal point should all be retained if
resolution allows. For example 4,756 + 2 = 4,758. Throwing away the "475"
and keeping only the "8", on the grounds that the second number has only one
significant digit, would make no sense at all.

Limiting the overall number of digits means limiting the "resolution", as is
done in machine computation, and that is not the same as dropping decimals,
though it it could involve that.

In the case above, if 10.5 and 105 really both had three significant digits,
then, in floating point, they would have been expressed as 105E-1 and 105E0
and the difference would be -945E-1, which is three significant digits (we
don't count the exponent and the minus sign).

From that standpoint, David's argument that the result should have been
-94.5 is correct.

Another example: We know that 9,995 + 7 = 10,002. But, if the resolution is
limited to four digits, then the result would be expressed as 1000E1,
meaning 1000 x 10 (and, the least significant digit, "2" would have been
lost). The result would not have been "0002", unless the machine experienced
an "overflow error", which should case an error message to be generated.

---------
Cyrus W. Roton <cwrotoniwvisp.com>
MITA tech, WebMaster <http://www.mitatechs.com>
Chairman, Ridgecrest Apple User Group <http://www1.iwvisp.com/croton/>

At 07:19 AM 01/17/2006 -0800, John Baxter wrote:
>The slide rule was so much easier for this multiplication stuff.

Hear, hear! I still have my father's good bamboo slide rule that he passed
on to me. Have it somewhere, with its torn leather case. Just a museum
piece now.

Ah, for the days when one could *feel* a computation ...

Edward
Art works by Melynda Reid: http://paleo.org

Part of the issue in this is that we're talking about more than one kind of
computation. For financial data, you need full precision at all times. For
example, when doing calculations on dollars and cents, you almost always
have to keep two decimal places, no matter how many significant digits that
means (with notable exceptions). Just to complicate matters, occasionally
you have to keep even more, such as in dealing with interest calculations.
This is why money amounts should never be stored in floating point, but
rather in fixed point (integer storage with an appropriate scale factor
handled in software, 100 in the case of dollars and cents).

Scientific applications tend to work mostly in the realm of precision, or
significance -- in our ten-centered world, "significant digits" even though
the math is radix-agnostic. But you can't tell the precision from the
external representation. The number 0.2 (radix 10) appears to have "one
significant digit" of precision -- but try to represent it in binary and it
appears to have as many bits of precision as you can store in your floating
point representation. Neither conclusion is valid.

So Calculator appears to be making two errors. First, it is using a single
set of rules for all calculations even though it doesn't know what kind of
calculation is being done. Second, it's trying to derive precision data
from the numbers entered, and the deduction is not valid.

There isn't a simple answer. Calculator's error is in assuming that there is.

Edward
Art works by Melynda Reid: http://paleo.org

On Jan 17, 2006, at 9:52 PM, Edward Reid wrote:

> This is why money amounts should never be stored in floating point,
> but
> rather in fixed point (integer storage with an appropriate scale
> factor
> handled in software, 100 in the case of dollars and cents).

And this, in turn, is why Microsoft shipped two versions of their
early (and very good) BASIC for the Mac. One had a "pi" in the icon
and did floating point; the other had a $ in the icon and did fixed
point. One received both versions in the box and generally installed
both.

   --John

--On January 17, 2006 9:52:23 PM -0800 Edward Reid <edwardpaleo.org> wrote:

> At 07:19 AM 01/17/2006 -0800, John Baxter wrote:
> Hear, hear! I still have my father's good bamboo slide rule that he passed
> on to me. Have it somewhere, with its torn leather case. Just a museum
> piece now.
>
> Ah, for the days when one could *feel* a computation ...

Think Geek found a bunch of slide rules in a warehouse and was selling them
for quite sometime. I picked one up and was going to suggested it for the
Christmas gift (hardware?) issue but they ran out before then. They were
40-year old, never before sold versions. The box was a bit beat up and the
instruction book has a permanent bend from being wrapped around the rule,
but the rule itself is in awesome shape. It's plastic (my dad's is wood)
and all I can do with it is multiply. It's similar to the Microline 120 on
this page, but the rule is labeled as a Microline 125:
<http://www.sphere.bc.ca/test/pickett.html>

One day I'll go through the instruction book and learn how to use it.

BTW slide rules don't keep track of decimal points the user had to do that
themselves. That is probably why slide rule users are very good at order of
magnitude estimations. They had to have a feel for the size of the answer
when working on it.

Kevin

Well, I can not get the Calculator, version 4, with 10.4, to give me any of
the example errors.

No matter what mode I use, all my decimal places are
retained. It does not round off no matter what I have tried. I entered the
example calculations listed, and do not get the reported errors.

So, which version of the calculator is it that is reported to be giving such
errors? If it is a later version than 4, then I will not be in a hurry to
update.

Cyrus W. Roton <cwrotoniwvisp.com>
Chairman, Ridgecrest Apple User Group <http://www1.iwvisp.com/croton/>

As an engineer, I always thought the computer calulators were a waste of time. I have on my desk a TI 36X Solar. Full scientific machine, keeps 9 decimal places, statics, everything. Easy to use and inexpensive. The only way to go.

Jack Hodges hodgesjackmchsi.com

On Jan 18, 2006, at 10:33 PM, John Baxter wrote:

> And this, in turn, is why Microsoft shipped two versions of their
> early (and very good) BASIC for the Mac. One had a "pi" in the icon
> and did floating point; the other had a $ in the icon and did fixed
> point. One received both versions in the box and generally installed
> both.

Oops. Wrong. The $ version did decimal floating point (BCD, I
think), not fixed point.

Sorry.

   --John (who prefers using fixed point and scaling for money...at
least Missouri no longer has mils for sales tax purposes)

On Jan 18, 2006, at 23:40, Cyrus Roton wrote:

> So, which version of the calculator is it that is reported to be
> giving such
> errors? If it is a later version than 4, then I will not be in a
> hurry to
> update.

I just verified it with 10.4.4's v4.0.4. After doing "10.75 [return]
9.5 -" in RPN mode then showing and recalculating the paper tape, the
tape shows this:

        10.75 - 9.5
        = 1.25

but the calc display shows 1.3. Precision is set to 12.

-Bob