Re: Rounding errors

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

Date: 30 Aug 2004 13:29:13 -0700

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> It is apparent you have a strong attachment to the idea that
> truncation and rounding are somehow related. You're wrong. They
> aren't. How does the rounding operation know what truncation came
> before?

Rounding neither knows nor cares whether truncation has occured or
not. It merely operates as if there were an infinity of random digits
following the point of rounding.**

The link between rounding and truncation was entirely of your making
when you compared the sum of a set of truncated numbers and a set of
rounded numbers.

You were surprised when they didn't add up to the same value, and thus
didn't have the same average.

Much of this discussion has been me explaining in sufficient
excrusiating detail (but still, it seems, falling short) why the
truncated set should not add up to the same as the set of infinite
precision and why the truncated sets are short of your 'intuition'
that they should average 0.500.

** The numbers that you are using for stocks do not have an infinite
number of random digits following. Rounding will give an answer that
would be expected (by me) for a set that _did_ have an infinite number
of random digits and this would be a different answer. This is not a
fault of Cobol, nor even of rounding, but of an expectation that
rounding should give some other answer.

> >No. It does work exactly as _expected_ by me and by many others. If it
> >took you by surprise then you should take a course that takes away
> >that surprise by teaching you what you should expect.
>
> Classism via education. 'What do you expect from a high school
> dropout.' Next you'll trot out the family pedigree.

What _I_ expect from a high school dropout who claims to be self
educated is a recognition that perhaps they haven't been well served
by his tutors.

In fact you made claims about what your 'intution' told you. Now I am
certainly no classisist but it seems to me that the prefix 'in' might
mean 'without' so your claims to what you would expect was 'without
tuition'.

I am suggesting that you may get a different expectation 'with
tuition'.

> Let's deal with the issue rather than the players' social class.

I neither know nor care what your 'social class' is. In fact, I live
in a country which is ruthlessly classless.

My only concern are the issues that you present and that your
misconceptions and misinformation may become accepted by others.

> >> If Bankers' Rounding were used, there would be no error. Half the
> >> numbers ending with 500 would lose 500 and half would gain 500.
> >
> >Exactly. Use the right tool.
>
> Cobol doesn't give me a choice. Neither does Excel.

It is quite true that there is no provided function to do this. You
have to write the code yourself. Of course if the results aren't
acceptable (as you have explained) then use the wrong tool as you are
already doing, but _KNOW_WHY_ the answers may differ.

> >No. There is no 'rounding error introduced by Cobol'.
>
> Yes there is. You stubbornly refuse to acknowledge that when presented
> with factual evidence.

Show me an example where C or Pascal or a Primary School Maths book
gives a different answer and your claims may be looked at closer.

I will repeat:

> >Cobol merely
> >implements the number system. The number system works in particular
> >ways. Well defined ways. Ways that you fail to understand.
>
> Yeah, right. I'm too stupid to understand.

No. You are too stubbon. The way of determining whether the problem
lies in Cobol or in 'the number system' (or specifically your
expectations of this) is to try the same algorithm manually following
a text book, or using other mechanisms, such as an adding machine.

Don't use Excel it is known to be broken, but they won't fix it
because it gives numbers that everyone likes. ;-)

 
> One knows a debate is bottom-fishing when it relies on the other
> side's stupidity to make its point. If you had a valid point supported
> by FACTS, you would have made it. Readers will conclude facts aren't
> on your side.

I would be very interested to see what others do think. I consider
that I have presented adequate facts and arguments. But then I would,
wouldn't I.

> I recall what the messages said and could write a tutorial on how the
> number system works.

OK. Write a tutorial.

> Please don't talk down to me.

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
    ... 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: [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 errors
    ... How does the rounding operation know what truncation came ... Cobol doesn't give me a choice. ... There is no 'rounding error introduced by Cobol'. ... Readers will conclude facts aren't ...
    (comp.lang.cobol)