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

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

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

Thanks anyway

Zonnald

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

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$1b6c18a

> 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

function NewRound(x: Extended): Integer;

begin

Result := Trunc(x + 0.5);

end;

So long,

JB

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.

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