Round to Even (aka Banker''s Rounding) - The final function
-
Heh... and this is the SECOND one on the same subject...
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Wanna start a third Jeff
Or should that be 1/3 or .33
Damn, did it again, oops
Far away is close at hand in the images of elsewhere.
Anon. -
But for some cases there is just no need for BR - which is different from saying that BR is wrong - or rather, TR will do just fine.
Thus when you deal with numbers to 8 decimal places (or beyond) and you need to round to 2 decimal places TR and BR practically always produce the same result. To see this I tried this with 10 million randomly generated numbers in the range 0 to <1. Here is the result:
4 - 50,000 (actual=50,006)
5 - 5,000 (actual=5,057)
6 - 500 (actual=481)
7 - 50 (actual=47)
8 - 0 (actual=0)
Thus with 4 decimal places, 50,000 times out of 10,000,000 (of which 1,000,000 require rounding) the result of BR is different from TR. With 8 decimal places the result is 'always' the same. To find one that is different you need to sample more than 10,000,000 numbers. e.g. if you sample 100,000,000 at 9 decimal places you might get something like
4 - 500,000
5 - 50,000
6 - 5,000
7 - 500
8 - 50
9 - 0
I think you get the drift - and I'll let someone else do the fancy math to express this pattern.
In the real world where rounding is applicable, do we deal with numbers to 8 decimal places? I can think of at least one practical case where going to 8 decimal places is meaningless. Calculating interest on an amount involves a monetary value expressed to 2 decimal places and a percentage which is a number expressed to 4 decimal places (i.e. 11.25% = 0.1125). When you multiply the two it makes sense to keep only 6 (2+4) decimal places. Beyond that there is no meaningful additional accuracy. TR and BR do produce different results 500 times out of 10,000,000 calculations like that when considering 6 decimal places. Needless to say, the impact of this on my bank account is - something a lot less than negligible.
What about the impact on the bank? After all, the concept of fairness in BR was not meant for me but rather for the individual, in general, to have a sense that the bank is not getting rich on its millions of customers due to rounding.
Say the bank has 1,000,000 bank accounts and it does this calculation once a month. Based on the above patterns, 50 BR calculations will be different from the TR calculation. Even if it's all in favor of the bank we are talking about half a unit of currency. Thus nothing for the bank (or me) to get excited about.
I would be interested to know if anyone knows the kinds and volumes of numbers used in digital signal processing where- or so it was said on these two theads - BR is used.
-
"I would be interested to know if anyone knows the kinds and volumes of numbers used in digital signal processing where- or so it was said on these two theads - BR is used."
From thousands to millions of flops per second. And to back up the statement that this is an area where the rounding method is often used, here is Motorola's PDF on their Fast Fourier Transform implementations on their DSPs. You'll note that on page 117 they explain that their use of "convergent rounding" (another term for BR, and the one used by Matlab to describe it) on the DSP56001 and DSP56002 is to help produce numerically superior results.
It's also useful in comparisons of trending over various timeframes, as well as in tolerance trending and in some weight measurement applications. It's certainly not always needed, nor even always preferable, but there are places for it.
A somewhat newer trend is random rounding (when exactly halfway, round up or down randomly), which reduces bias is less than random sample sets, such as when you numbers ending in .125 occur far more frequently in your data than say ones ending in .375. While BR would still typically outperform TR in such instances, it is still more biased than random rounding in this situation. The problem with random rounding is that it's not a method in which a person could simply look at a number and tell you which way it would round every time, unlike BR and TR. The rounding results are somewhat reproducable, if you use a pseudo-randomizer with a fixed seed value, but still, not being able to apply a fixed rule to a number and know the result that will be produced prior to running it is disconcerting to some, hence BR still has plenty of traction in the "unbiased rounding" arena.
-
Heh... no way... two in the same lifetime is well enough for me
Learned a lot, laughed a lot, and puked a lot... time to move on --Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Lie.
Lynn, last time we crossed it was discussion about explicit dropping hash tables at the end og SP.
I stated it's an unnecessary overhead and you objected in your favourite style.
After set of testing your companion in that topic, Ninja, admitted I was right several times, he even wrote something like "How many time I need to admit...?"
Despite I was asking for it not from him.
But you just "disappeared". You are just not man enough to admit your mistakes.
So, you are undereducated, underqualified jerk with "too much proud" problem.
This is my personal observation. And I can back it up with facts. Unlike you.
_____________
Code for TallyGenerator -
David,
As for me there is nothing good in not having education essential for the job.
But at least you have guts to say it on public.
Respect.
I hope you not gonna let this situation stay for long. Best luck to you in that.
I could help you with rounding to those freaky bases, but we need to be on common ground first.
I cannot help you with BR here, because I know that BR is mathematically wrong and I don't do crap. (can afford such a luxury
)Sorry, but "double precision" approach is absolutely unacceptable for BR as it is defined. It involves implicit conversion of supplied precise DECIMAL representations to float ones. Some DECIMAL numbers don't have appropriate FLOAT representations and BR does not work as expected for them. It was discovered and discussed on first pages of the first topic about BR.
And "decimal" approach with an assumption of absolute precision of supplied values (requird by BR definition) is not acceptable because it makes impossible to process absolute majority of real world numeric values.
No one from BR advocates could show how to supply simple 1/3 to this function. "Implied zeros" don't let them do it.
That's why I don't see any point in wasting my time on building BR solutions.
But, I can help you if you are interested in real rounding solutions.
> BTW, can you remind me how TR will round down to .50 if the amount is > .50? I can't get my head round it.
Nothing special.
ROUND(@A*2, 0) / 2
Of course, there must be some frills around.
_____________
Code for TallyGenerator -
Now, when at least one person expressed an interest in a real solution?
Flamers can go ant rest.
But let's finish professional matter.
_____________
Code for TallyGenerator -
I deeply doubt it can help you in any way.
"Something not given by God could not be purchased in a pharmacy"
_____________
Code for TallyGenerator -
Michael, it's difficult to express your pattern because you did not tell which way you did generate the numbers.
So, it's not clear what they are.
And yes, as I said, it's really rear occassion when BR is different from TR. But every time it's happening BR is wrong.
_____________
Code for TallyGenerator -
Sergiy,
Unnecessary and wrong are two different things. It may not be necessary to explicitly drop temp tables at the end of a stored procedure, but that does not mean it is wrong to do it.
And I did some testing also, and on our systems it was inconclusive; sometimes faster and sometimes not.
-
Sergiy,
You also seem to have trouble recognizing the humor in Jeff's and David's posts.
-
How can BR be wrong? It is just a business decision.
Just like a company decides to always round down to nearest dollar, or upward to nearest dollar. It is just a decision. Such as adding "shipping & handling" to your order... When you accept the order, you also accept the additional charges. You can tell if they are "fair"? Is 4 dollar for sending a book to me in Sweden, from USA, fair?
I think so. Someone else might not think so.
BR is an implementation of a particular business rule.
Sergiy, it is not your problem, nor your business rule.
Learn to accept that other peolpe have other rules to live by than you.
N 56°04'39.16"
E 12°55'05.25" -
By definition.
By assumtion of of absolute precision of supplied numbers.
By implication of all trailing zeros.
By limiting list of processed values to the set of precise decimal representations.
By dragging trends of continuous values down (average of BR rounded values between 0 and 1 always < 0.5)
And whoever makes any business decision it does not change the fact that BR concept is wrong.
Peter, are you sure you can find any of my posts where I objected anybodu's right to apply any stupid rule?
It was never a subject, actually.
Peter, learn to leave with knowledge that someone could be better in something than you.
_____________
Code for TallyGenerator -
I know most intelligent people are better in more things than me. Always has been that way.
What I object to is your stupidity.
The BR algorithm is designed the way it is. No more, no less.
And you are at it again. Who are you to tell BR concept is wrong? It all comes down to computer interpretation of algorithms of available precision.
I know you don't like it. You have told us many times. That's fair.
But other people like the BR algorithm and use it in real-time applications.
Do you mean all these people are stupid?
Who are you trying to impress?
N 56°04'39.16"
E 12°55'05.25"
Viewing 15 posts - 301 through 315 (of 378 total)
You must be logged in to reply to this topic. Login to reply