Re: When double precision isn't very precise

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


Hello Cor ,

I have really made endless programs in past in Cobol for different
systems.
I am me not aware that bankers rounding was used in the first ones.
We simply had to do that forever ourselves.

But maybe there are versions who do.

Well this doesn`t surprise me as my 2 COBOL co workers who worked for 30
years in the industry where also stating that it wasn`t like that in COBOL
untill i showed them a simple calculation an challenged them to do the same
in COBOL , it turned out that i was right and there COBOL production system
used bankers rounding ( as allmost all program languages do by default )
This isn`t a bad thing however you must be aware of it when you perform
certain calculations

This is knowledge that i feel should be in every standard programming course
, but as i noticed in practice i still tell my new co workers something new
even if they worked for years in the industry and hold multiple
certifications or even have university degrees :-( .

I learned it from my tutor in the first week i started to become a
commercial programmer ( i had a on the job training from a verry
experienced developer , who wrote on the core modules of the EXACT
corporation http://www.exactsoftware.com ) and already then ( 1998 ) he
told me that 95% of the coders are not aware of that simple fact .

Are you telling in Albert Hein as well that they should round to even.
That it is better I know for a long time, but tell it to all the end-users
of your company

No Midpoint rounding away from zero that is something different as just
rounding to even , for a fact "Midpoint rounding away from zero" is rounding
how it is tought at every elementary school , so i guess that if they
wouldn`t use that method on your receipt you would go to the manager and
tell them to correct your payment .


lets get to the basics

A + B = C
2.5 + 3.5 = C

with common rounding we get 3 + 4 = 7.
with banker's rounding we get 2 + 4 = 6.

wich one is correct ? see the problem Albert Heijn `s POS software
developer is facing :-)

If you always round away from zero you'll always be over. if you round
some numbers up and some numbers down you'll be closer to the correct
answer.

You should NEVER implicitly round numbers if they matter at all. always be
explicit if your values really matter.

P.S.

AFAIK every POS system just rounds the final sum with midpoint rounding away
from zero



regards



Michel







"Cor Ligthert[MVP]" <Notmyfirstname@xxxxxxxxx> schreef in bericht
news:u$9GYOh2JHA.6056@xxxxxxxxxxxxxxxxxxxxxxx
Michel,

I have really made endless programs in past in Cobol for different
systems.
I am me not aware that bankers rounding was used in the first ones.
We simply had to do that forever ourselves.

But maybe there are versions who do.

Are you telling in Albert Hein as well that they should round to even.
That it is better I know for a long time, but tell it to all the end-users
of your company

But thanks for the information

:-)

Cor

"Michel Posseth [MCP]" <MSDN@xxxxxxxxxxx> wrote in message
news:Oa7Nn%23e2JHA.2656@xxxxxxxxxxxxxxxxxxxxxxx
Be aware that standard in Net ISO rounding (banking rounding is used)

every computer language i know of does bankers rounding this includes
even Fortran and COBOL
most people are just not aware of that fact , so it is not something
specific to VB or .Net

( just wanted to make that clear )


However in all those languages ( even COBOL ) it is possible to use
common rounding in .Net you do that with system.math.round
and the away from zero option

"By default, Math.Round uses MidpointRounding.ToEven. Most people are not
familiar with "rounding to even" as the alternative, "rounding away from
zero" is more commonly taught in school. .NET defaults to "Rounding to
even" as it is statistically superior because it doesn't share the
tendency of "rounding away from zero" to round up slightly more often
than it rounds down (assuming the numbers being rounded tend to be
positive.) "


HTH

Michel


"Cor Ligthert[MVP]" <Notmyfirstname@xxxxxxxxx> schreef in bericht
news:efL%23KnR2JHA.4416@xxxxxxxxxxxxxxxxxxxxxxx
Peter,

The double is not meant to be used in financial computing.
This is not even by design, this is simple general used behaviour.

For accounting is the decimal meant.

Be aware that standard in Net ISO rounding (banking rounding is used)

Cor

"Peter B. Steiger" <see.sig@xxxxxxxxxxxxxxxxx> wrote in message
news:8d-dnVDaj4fyoo7XnZ2dnUVZ_j1i4p2d@xxxxxxxxxxxxxx
I wrote a quick-and-dirty accounting routine that added up charges and
payments to show a running balance on someone's ledger. Our QA team
reported that it is producing the wrong balances, and sure enough it
was.
The answers were coming back with umpteen decimal places written in
scientific notation, e.g. 1.23456E-9.

I thought I'd play it smart and wrote a function to do all the work in
integers - it receives the running balance and new amount, multiplies
them by 100 into integer variables, adds the two integers, and divides
the result by 100. It's stupid that I have to do this because our
state-
of-the-art computer can't add two-place numbers together and come up
with
the right answer, but at least it was an easy enough kludge.

Now it turns out it's also converting to integers wrong. For example,
with a balance of $595.17 added to $80.00, the new balance is $675.16
because it multiplied 595.17 * 100 and came up with... 59516.

The balance and amount are both double precision, so I did some
testing:
Module FloatTest
Sub Main()
Dim nFloat1 As Single
Dim nFloat2 As Double
Dim nInt1 As Integer
Dim nInt2 As Integer

nFloat1 = 595.17
nInt1 = Int(nFloat1 * 100)
Console.WriteLine("Int of single " & nFloat1 & " * 100 is " & nInt1)
nFloat2 = 595.17
nInt2 = Int(nFloat2 * 100)
Console.WriteLine("Int of double " & nFloat2 & " * 100 is " & nInt2)
End Sub
End Module

The results? Multiply a single-precision number with two decimal
places
by 100, and you get the right answer (in this case, 59517). Multiply a
double precision number by 100 and you get the wrong answer (59516).

I know FP math produced weird results on old CPUs (8086 through 80486),
but I would have thought for sure some processor genius would have
fixed
the problem by now. Is this a known bug, or am I using the wrong data
types for my purposes, or what?

--
Peter B. Steiger
Cheyenne, WY
If you must reply by email, you can reach me by placing zeroes
where you see stars: wypbs.**1 at gmail.com.






.

Relevant Pages

  • Re: Rounding errors
    ... >fractions with an arbitrary precision then the average will indeed be ... That's because a fraction will not produce zero. ... After rounding was applied, the sum became 500,500. ... On one report you might say you are ...
    (comp.lang.cobol)
  • Re: Rounding errors
    ... There are a VARIETY of rounding options. ... an upwardly compatible way) to COBOL. ... > collection of numbers in format v999 and we want to round them to v99. ... > digit of zero, a second containing 1-4 and a third containing 5-9. ...
    (comp.lang.cobol)
  • Re: Blow me away, (long) does not truncate.
    ... I see nowhere that rounding is ... If rounding can only mean round to nearest, ... The concept of rounding toward zero is not ambiguous at all. ...
    (comp.lang.java.help)
  • Re: Problem(s) with round-to-nearest
    ... the usual integer division, etc. correspond to rounding towards zero, ... remainder, I have reduced the problem analytically to an equation ... For the Nth-Root function: d is never zero... ...
    (sci.math)
  • Re: division by 7 without using division operator
    ... integer for which it fails? ... It depends on the implementation's precision and the rounding mode. ... the exact difference ... towards zero, ...
    (comp.lang.c)