Errors with ROUND function

I have a onCalculate procedure where two (FLOAT)fields from table are multiplied, the result is put into the calc field type FLOAT.  Now I have to round this to the nearest integer... 0.00-0.49 -> 0.00
           0.50-0.99 -> 1.00 right?

Well when 1.5 is multiplied by 1 I get 2 (i.e. round(1.5*1)=2), when 1.5 is multiplied 3 I get 4 (round(1.5*3) = 4) when I know I should get 5.  

This happens on several different machines, but not in EXCEL.

So what gives is there another way to round this equation and get a expected result?

Please help soon

Zonnald
LVL 1
ZonnaldAsked:
Who is Participating?
 
JimBob091197Connect With a Mentor Commented:
Hi

If the decimal is .5 then Delphi rounds up if the number is odd and down if the number is even.

Round(0.5) = 0
Round(1.5) = 2
Round(2.5) = 2
Round(3.5) = 4
Round(4.5) = 4
Round(5.5) = 6
etc.

In your example:
Round(1.5) --> 1 is ODD, thus gives 2.
Round(1.5 * 3) = Round(4.5) --> 4 is EVEN, thus gives 4.

This IS by design!
Regards,
JB
0
 
ZonnaldAuthor Commented:
This is new.

Maybe I should throw away the maths degree and 10 in the finance industry and go fishing?

This destroys everything I ever believed in mathematics.

Oh well looks like ol' Bill Gates will just have to go out of business becuase his stupid EXCEL program gives this result:
1.5=      2
2.5=      3
3.5=      4
4.5=      5
5.5=      6
Does Borland really believe that they can rewrite mathes?

Now that I know that Delphi, which I am really devoted to,is stupid - I will give the (100.5) points anyway!

I guess I could lower myself to add 0.00000000000000000000000000000000000001 to my number before rounding it.

Thanks anyway

Zonnald


0
 
ZonnaldAuthor Commented:
Hehe...  You're clearly not too charmed with Borland, but most programming languages work this way, including MS Visual Basic.

Their logic is that the decimal digit 5 (in 1.5, 2.5, etc.) is in the middle, and thus shouldn't always be rounded up.  If the decimal is 1, 2, 3 or 4 it rounds down.  If it is 6, 7, 8 or 9 it rounds up.  Thus there are 4 digits below 5, and 4 digits above 5, so to keep things fair (???) they alternately round it up and down.

Don't blame me, I'm just a humble programmer...
JB
0
 
JimBob091197Commented:
JimBob,

Further to our discussion - ticked off? a little.  Only because the doco is poor on this function (and many others).  The final word comes from the objectpascal forum :
In article <01bcfe6b$ed9a00e0$1b6c18ac@twattron>, Alltel wrote:
> Has anyone noticed that the ROUND function for X.5 rounds
> up when X is an odd number

Yep.

Contrary to what you might think, it isn't a bug; the behavior of the Round
function is working as designed (though I believe the documentation may be
incorrect). The rounding algorithm that you've noted is known as "banker's
rounding", and is the algorithm implemented in the Intel CPU, is the IEEE
recommended algorithm, and is designed to statistically balance the effect
of rounding. Always rounding up has negative statistical consequences.

If you can't live with the Intel/IEEE/Delphi rounding algorithm, and
require an algorithm which always rounds up, use this:

function Rounder(X: Extended): Extended;
begin
  Result := Trunc(X) + Trunc ( Frac(X) * 2 );
end;

--
Rick Rogers (TeamB) | Fenestra Technologies

I stand very corrected - I quess not too many "Bankers" in Australia pay enough attention to this IEEE standard.

I will now revolutionize banking in Australia (I guess I'm dreaming now).

So long

Zonnald
0
 
ZonnaldAuthor Commented:
The function given is similar to one I use in VB, which has the effect of ALWAYS rounding up.  The Delphi equivalent is:

function NewRound(x: Extended): Integer;
begin
    Result := Trunc(x + 0.5);
end;


So long,
JB
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.