Re: Rounding errors

From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 09/01/04 

Date: Wed, 01 Sep 2004 01:39:01 GMT

On 30 Aug 2004 12:39:58 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> Truncation lowers the average to .499..5 because it discards
>> information. That's easy to understand.
>
>Good, because you started by saying that all v99, v999, v9999 averaged
>.5000 which meant that even though there was some discarded it still
>somehow added up to the same total.

Right. You win that point.

>> Rounding is supposed to maintain the average.
>
>It does. It maintains the average of the infinite precision original
>real numbers. With enough digits the average is close enough to
>0.500. Rounding maintains this with an average of 0.500.
>
>> It's not supposed to push it upward,
>
>It only 'pushes it upwards' with respect to how much truncation
>'pushed it downwards'. Your numbers of 0.5005 were _wrong_ and were
>not the result of valid experiment.

What if the numbers were not truncated, computed or rounded? I posted
a demo of that case to which you had no reasonable answer.

>> but it does in Cobol due to a bug.
>
>No. Wrong. The rounding mechanism is well defined and works
>identically in primary school textbooks, mechanical adding machines,
>C, Java, and Cobol.

You're incorrect. It doesn't work that way in C# nor in JavaScript (I
don't know about compiled Java).

This looks like a Brooklyn Bridge defense. Everyone else is doing
wrong.

>> You try to explain away the bug by linking the two, by claiming that
>> rounding somehow recalls and corrects truncation error.
>
>No. It doesn't 'recall' anything. It completely ignores whether it
>has been truncated or not. Rounding, say, to cents, takes the two
>digits and inspects the 3rd. It neither knows nor cares whether there
>are no digits beyond this or an infinity of them. Nor does it care
>whether these digits are (or would be) all 9s or all 0s.
>
>This means that you _can_ truncate beyond the third digit without
>affecting the result of rounding, which is entirely predictable.

You've said that over and over. What's the point of truncating to
three digits followed by rounding to two? Why not just round in the
first place?

>You continue to say 'rounding error' when applied to an average. there
>is no _the_ rounding error. _A_ 'rounding error' is the difference
>between each individual original infinite precision real and the
>rounded number. For example 1.23761.. rounded gives 1.24 with a
>rounding error of .00238.. The total of the infinite precision reals
>and of the rounded numbers will be about the same for even
>distributions.

Yes, and an infinite number of random errors average to zero. The
problem is Cobol rounding is not random. It pushes the average upward
always, unless the numbers happen to end with zero.

>Now here's the thing: read this 3 times, then come back tomorrow and
>read it again:
>
> The difference between the set of infinite precision reals and
> the truncated set,
> and
> the difference between the rounded set and the truncated set
>
> are _identical_ (in ideal conditions)

It didn't take that long. That's true only in the case where rounding
removes one digit. If we take the more common case of dollars.cents
rounded to dollars, there is an upward bias of half a cent.
>
>If the set of infinite precision reals adds up to the same as the set
>of rounded numbers (which it does under ideal conditions). Then any
>set that is less than that set (such as a truncated set) will have the
>_same_ difference to the two sets that have the same total.
>
>How hard is that ?

It's based on a false premise -- that the truncation error is offset
by the rounding error. They are two separate issues that don't
necessarily cancel out.

>> When I present cases where there was no truncation to correct, you
>> brush them aside by saying the rules are different for integers.
>
>Rounding works on real numbers of infinite precision and random digits
>beyond the rounding point to create numbers with fixed precision.
>
>If you use it on numbers that do not have those characteristics then
>either you put up with the errors (of usage) or you modify the
>technique to cater for the differences that you _should_ expect.

What does that mean .. in English? There is no reason rounding should
work differently on dollars rounded to thousands than it does on cents
rounded to dollars. As i pointed out in another thread, they're both
scaled integers at machine level.

>> Your argument is an appeal to ignorance.
>
>I really don't know what to say without it seeming like an ad hominem
>attack ;-)

Just say I'm an idiot. You've done it before. :)

>Perhaps all this is a troll on your part to get me to throw insults at
>you.
>
>> Rounding is broken.
>
>I suggest that you try using C or Java or Perl or just follow the
>instructions in a primary school maths book and see what answers you
>get. When you find some definition of rounding that gives better
>answers than Cobol does you can then present that here.

I have found a better definition. So have others who are serious about
the subject. It's called Nearest-unbiased.

Relevant Pages

  • Re: Rounding errors
    ... Rounding maintains this with an average of 0.500. ... It only 'pushes it upwards' with respect to how much truncation ... You continue to say 'rounding error' when applied to an average. ... If the set of infinite precision reals adds up to the same as the set ...
    (comp.lang.cobol)
  • Re: Rounding errors
    ... >There is no 'error' in rounding. ... >precision numbers and to give an accurate representation in a limited ... >When that set is rounded to 2 digits of precision it only needs to ... >truncation does not represent. ...
    (comp.lang.cobol)
  • Re: Rounding errors
    ... How does the rounding operation know what truncation came ... I am suggesting that you may get a different expectation 'with ... > by FACTS, ...
    (comp.lang.cobol)
  • RE: [OT] Rounding v Truncation, was: Re: Platform Support vs.
    ... Subject: Rounding v Truncation, ... > If you don't exploit EXPLICIT conversion then you had better know the ... If you have received the email in error, please notify TransGrid ...
    (comp.os.vms)
  • Re: Rounding errors
    ... digits then the average is _NOT_ 0.500. ... Rounding of the original set of long numbers, ... When you round the numbers to two digits what existed beyond the 3rd ... so the truncation doesn't matter. ...
    (comp.lang.cobol)