Re: Rounding errors

From: Richard (riplin_at_Azonic.co.nz)
Date: 08/30/04 

Date: 30 Aug 2004 12:39:58 -0700

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.

> Rounding is supposed to maintain the average.

It does. It maintains the avrerage 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.

> 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. There is no 'bug'. Complain to whoever invented
the number system.

> 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 predicatible.

> It sounds plausible to the innumerate

I think you have that around the wrong way.

> because both remove digits from the right
> side of a number, and the rounding error is approximately equal to the
> truncation error in the other direction.

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.

The total of the truncated set (truncating the reals) will (for
positive numbers) be less than either the set of reals or of the set
of rounded numbers.

The amount it is less is dependent entirely on how much is discarded.
The difference between the total of the reals and the total of the
truncated set will depend on whether you truncate to 6 or 3 digits.

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)

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 ?

> 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.
 
> Your argument is an appeal to ignorance.

I really don't know what to say without it seeming like an ad hominem
attack ;-)

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.

Relevant Pages

  • Re: Rounding errors
    ... It maintains the average of the infinite precision original ... With enough digits the average is close enough to ... Rounding maintains this with an average of 0.500. ... >It only 'pushes it upwards' with respect to how much truncation ...
    (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)
  • Re: Rounding error when doing float-to-integer
    ... there is no "round to seven ... I said that the rounding error was due to first rounding to seven ... > conversion of the 0.002 to binary, which you seem to be ignoring. ... No I am not ignoring it, the rounding error alone does not seem to ...
    (comp.lang.fortran)