Visible currency rounding

You described it in the most precise way.
I needed a function that would round down the number if the followin digit
is less then 5,
and would round up if the followin digit is greater then 5,
and if the followin digit is equal to 5 then it will test if the last digit
to remain in the number is odd or even and then round it up if it is odd or
leave as it is if it is even.
I think this is called "Round half to even" as a "tie braking rule".

But even more accurate description is here:
http://www.xbeat.net/vbspeed/i_BankersRounding.htm

I must confess I did not have an idea that this was called "Gaussian
rounding".

In my case the function needs to start from the least available right
standing digit for the given number and round consecutively from there to
the left untill the desired digit position is reached, one digit at a time .
This way it ensures that any boundary cases be treated correctly.
The practical need for this is when I had to fill in an invoice, on each row
I wold have an intermediate number which is a result of multiplication of
amount by unit price (i.e. an item's sum), which in the general case will
not be an exact number . Then I would need to round this number to a
sensible (currency) format and only then to add the numbers up in order to
get the final amount for the invoice. In this way all numbers add up
correctly and there is no difference in the final amount.

As for the example where 23,574 rounds to 23,57 , this is the intended
result as described above.
Thanks again for the clarification you've given in your post.

Regards,
toodr

I have given my reasons in an explanation to a post by Luuk in this present
discussion.
But I think this is not an overkill, because if we have a significantly long
number
and we just look at the 3 digits to the right of the comma separator
and just drop the rest of the digits to the right of them - we shall be
risking to get an incorrect result.
The correct way to round the number will be to start at the rightmost
available digit and drop one digit at a time,
untill we reach the desired digit position.
At least this is correct in my oppinion.

Regards,
toodr

I have given my reasons in an explanation to a post by Luuk in this present discussion.
But I think this is not an overkill, because if we have a significantly long number and we just look at the 3 digits to the right of the comma separator and just drop the rest of the digits to the right of them - we shall be risking to get an incorrect result. The correct way to round the number will be to start at the rightmost available digit and drop one digit at a time, until we reach the desired digit position. At least this is correct in my opinion.

Paradoxically, this is certainly not the way that rounding - even banker's rounding - is normally achieved.

You would round 1.23456 to 1.2346 and then to 1.235 and 1.24 (using either scheme).
Single rounding (again using either scheme) gives 1.23. This makes sense, since the original number is clearly closer to 1.23 than to 1.24.

It is a general principle that you should always round numbers once; if you do so repeatedly, you will indeed get different results. http://en.wikipedia.org/wiki/Rounding#Double_rounding says:

In _Martinez v. Allstate_ and _Sendejo v. Farmers_, litigated between 1995 and 1997, the insurance companies argued that double rounding premiums was permissible and in fact required. The US courts ruled against the insurance companies and ordered them to adopt rules to ensure single rounding.

Some computer languages and the IEEE 754-2008 standard dictate that in straightforward calculations the result should not be rounded twice. This has been a particular problem with Java as it is designed to be run identically on different machines, special programming tricks have had to be used to achieve this with x87 floating point.[...]

Brian Barker

Thank you for the reference in your answer. That is indeed the case and I
must admit that my logic is wrong.
I will have to rethink all this stuff. You are certainly right to point out
that the original number is closer to the result as you have suggested.

My fault ! And apologies to the other participants in this discussion.

Regards,
toodr