Re: Rounding errors

From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 08/25/04 

Date: Wed, 25 Aug 2004 01:31:35 GMT

On 24 Aug 2004 12:36:02 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> Intuition tells us half the numbers will round up and half will
>> round down. Given a very large sample, the average will remain .500 ..
>> we think.
>
>It may be what you had thought, but why do you assume that everyone
>else thought that ?

Because it's in the Cobol standard.

>> Suppose we have a million random numbers formatted v999, adding up to
>> 500,000. Let's divide them into three groups: one containing rightmost
>> digit of zero, a second containing 1-4 and a third containing 5-9.
>> Let's round each group the Cobol way and sum the rounded numbers.
>>
>> Digit Population Sum
>> 0 100,000 50,000
>> 1-4 400,000 200,000 - 1,000 (-.0025 * 400,000)
>> 5-9 500,000 250,000 + 1,500 (+.0003 * 500,000)
>> Total 500,500
>
>Your methodology is flawed. In fact you have made a gross statistical
>error.
>
>The fault is that you have claimed they were 'random' when you have
>contrived to truncate after the third digit. If they had not been
>truncated and you had left the remaining additional digits in, say, a
>v99999999 and then added them up you would have got very close to the
>total of 500,500.

You're all wet. It is intuitively obvious that collections of random
numbers formatted v99, v999 or v9(infinity) will average .50000.

>So the flaw is not that the rounding at the third digit increased the
>rounded total, but your truncation of the 4th and later digits
>decreased the original total.

You are wrong. Support this with an example.

>> Here's another way of looking at what we did. We discarded the
>> rightmost digit, producing numbers that look like v99. Then we left
>> half of them unchanged and added .01 to the other half. By doing so,
>> we increased the total by (.01 * 500,000) = 500.
>
>No. The rounded answer is correct. You had trucated the original
>random numbers by an average of .0005 in making them v999. 1,000,000
>x .0005 is the 500 that rounding correctly restored.

The rounded answer is incorrect.

There are two types of ignorance -- simple and volitional. The former
simply doesn't know; the latter doesn't WANT to know and becomes
hostile when you attempt to educate him. Most of us have encountered
the latter type in our daily lives.

>I have done systems that carry the rounding forward. That is when the
>first number is rounded the difference is added to the next number
>before that is rounded (or truncated, as preferred). This ensures
>that the total is always correct rather than being randomly incorrect
>by a small amount.

Rounding intermediate results is THE classic beginner's mistake. It
doesn't surprise me that you advocate it.

The right way is to carry intermediate results to say six digits right
of decimal and round them only when going to a report. The wrong way
is to add rounded numbers into a total. I'm an autodidact but assume
they used to teach this in Programming 101.

>> I find it ironic that we criticize floating-point for being too
>> inaccurate for business use due to rounding errors
>
>No. Wrong. "We" don't criticise floating-point for 'rounding errors'
>at all. We criticise floating-point for not being able to represent
>numbers exactly.
>
> a = 0.50 * 2.0
> if ( a == 1.0 ) <- is not true

Same thing. The error is in rounding a to .99999999 rather than 1.0.

>> while at the same
>> time we've been making much larger rounding errors for 40+ years.
>> Single-precision floating-point errors are on the order of 10 parts
>> per million; double-precision is orders of magnitude better. Our error
>> is 500 parts per million.
>
>Why do you insist on using plural for your singular errors ?

Because I'm addressing more than one Cobol programmer.

---------------------------------------------------
If someone else can show an error in my logic, without rancor, I'd be
delighted to address his or her argument. Flammage offers neither
information nor entertainment .. unless it's artful. The level of art
in evidence here doesn't support the effort to respond.

Succinctly, it's like 'pissing into the wind.'

Relevant Pages

  • Re: Win32Forth & negative zero
    ... it's pretty straightforward; you look at the digit ... > after the one you want to truncate to. ... > If you want to be really fancy, there are some more complex systems that ... > only round up 5s in certain circumstances, but I believe those are usually ...
    (comp.lang.forth)
  • Re: [PHP] sprintf() oddness
    ... it's more accurate to use the preceding digit to determine rounding. ... What you describe is "if even then round down else round up". ... Why is the behavior of rounddifferent to that of sprintf()? ...
    (php.general)
  • Re: Need help implementing EPA rounding method
    ... not simply round up, but rather round to the nearest EVEN whole number. ... The rule only makes a difference when the tenth digit is .5. ... In order for this to work, however, I need Excel to only ...
    (microsoft.public.excel.worksheet.functions)
  • Re: Need help implementing EPA rounding method
    ... as vba uses Bankers Rounding. ... not simply round up, but rather round to the nearest EVEN whole number. ... The rule only makes a difference when the tenth digit is .5. ... In order for this to work, however, I need Excel to only ...
    (microsoft.public.excel.worksheet.functions)
  • Re: Using Float For Currency
    ... >> I have some methods that manipulate floats that represent a currency amount. ... round2 - unbiased rounding for floats ... The earlier article reported that the best way to round ... numbers is to always round up when the first digit dropped is 5. ...
    (comp.lang.ruby)