Bankers Rounding
-
What do you think is the result of
select 2./3000 * 1000
Is it actually 2/3?
Is it valid representation for 2/3?
Now try with
select 10./7998*1000
How precise is your result?
Is it actually > 0.125 or not?
Will be result of BR correct for this value?
_____________
Code for TallyGenerator -
Why should I try again?
SELECT Round(2.0/3.0,3) returns .667000. That's where the "7" comes from.
Remember, we're not arguing the function as written, which is flawed, even after you "fixed" it. You're the one who claims it's the concept you take issue with, not the function, so why bring it up? We're discussing the concept of Banker's rounding. When written correctly, Banker's Rounding will also return .667 for this value.
Banker's rounding, written properly will return the exact same results as traditional rounding for 2/3. I've said that repeatedly now, and I won't be changing my mind, but keep trying if you think otherwise.
-
Don't change topic.
It was not about result of ROUND.
It was about valid decimal representation of 2/3.
What ROUND() is doing in you post?
P.S. David, you're starting to make funny noises.
Control yourself.
_____________
Code for TallyGenerator -
> Banker's rounding, written properly will return the exact same results as traditional rounding for 2/3. I've said that repeatedly now, and I won't be changing my mind, but keep trying if you think otherwise.
Can you prove it?
You still failed to supply 2/3 as a parameter to BR.
Can Bankers Rounding be written properly in any computer programming language?
Properly enough to accept 2/3 as a parameter?
_____________
Code for TallyGenerator -
"What do you think is the result of
select 2./3000 * 1000"
No. Seriously, did you think we'd fall for that. You're using implicit conversion issues to intentionally introduce bugs. The built-in Round() has the exact same problem with that calculation (it returns 0.666000 which is also incorrect). That's the equivalent of getting the results of "SELECT 3/2" and saying that 1.000 is therefore the correct 3 digit precision representation of 3/2. 0.667 is the proper representation for 2/3 if you want 3 digits to the right of the decimal, using either rounding method, if you avoid implicit conversion bugs. You are getting desperate when you want to introduce SQL Server specific conversion issues and blame them on some rounding concept.
Not even going to do your other calculation, as it's the same crap you pulled in the first one. Hell, you even bitched about implicit conversions yourself in this thread, and I wouldn't be terribly surprised if I found another of your posts where you said something like "Don't use implicit conversion, newbie".
-
I put ROUND() in my post so that you could repeat the calculation. Apparently you are the only person in this thread who thinks .666 is the proper representation for 2/3, instead of the more accurate .667. I don't even have to run code to tell you the answers. Since the third 6 is followed by a fourth 6, the third 6 becomes 7. I learned that one in grade school, and it holds true in both methods of rounding under discussion.
-
"Can you prove it?
You still failed to supply 2/3 as a parameter to BR."
Absolutely, I just fired up .NET 2003 and ran the following line:
Debug.Write(Math.Round(2 / 3, 3))
It returns 0.667. You'll be shocked to know that changing it to 4 digits returns .6667. Of course, some of us could just look at the number and tell you that.
So admitting defeat now, or are you going to try and lead us down a different sidetrack which will have nothing to do with Banker's Rounding?
Again, you asked for proof, I provided it. Time to fess up.
-
Oh heck yeah! Sorry Cory... I forgot about that!
I remembered the fax but forgot the message 
--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) -
How many pieces of flair do they make you wear at work?
-
Ummmm.... yeah.... I'm going to need you to move your desk to the basement.
--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) -
I actually own a Red Swingline.
Piece of trivia. Red Swinglines did not exist when Office Space came out. Due to the subsequent volume of requests for them, they released one.
-
Sergiy,
Of course I noticed the post that fixed the original function. This is the "-Add more of the red tint. -Worked fine, thanks" exchange in my little "non-technical' recap.
The biggest problem with this bankers rounding discussion is your persistence of trying to prove that this concept is wrong because it is not mathematically precise. And you are right, that it is not mathematically precise. It is not supposed to be the most precise rounding method. It has nothing to do with precision. It is a statistical method of even distribution of fractional transactions. And it was designed to work with statistically large number of transactions. David failed the most when he tried to deal with some of your 'proof scenarios' that were not applicable in the first place. Like the sales tax example you provided or the 2/3 number rounding - wrong examples because they have nothing to do with the Bankers Rounding. On the other hand the example of processing 20000 numbers using the BR function was a perfect example and worked fine proving that BR works the way it was designed to work. Would you accept the Bankers Rounding method if it was called anything but Rounding? Maybe Bankers Conversion?
As far as the precision is concerned any representation of 2/3 in any computer system is imprecise by the nature of this number and the way we store and present numeric values using the computers. Because of the numbers like 2/3 the whole concept of rounding (not BR) was invented. The only thing you can do is to accept a degree of precision that is acceptable for your particular case.
I have seen a lot of your posts on this site and I got an impression that you are a very bright SQL programmer. And this might be your greatest weakness. It looks like you think you are so good that you totally refuse to attempt to understand others’ point of view.
I (and most of us watching this thread) can not “ agree, the conception of the function is proven wrong” because the function works according to the requirements. That is the point you missing.
---------------------------------------------
[font="Verdana"]Nothing is impossible.
It is just a matter of time and money.[/font] -
There is no inbuilt ROUND()
Where did you see any reference about built-in ROUND() in 2./3?
Result 0.666000 is correct if you take into consideration actual precision of the value.
You've got 3 digits precision only, so only 3 digits are trustful.
Now, you're clearly telling lies when describing result of SELECT 3/2.
Result is "1", not "1." or "1.000".
1.000 is a result of conversion of single digit precision value "1" into DECIMAL(8,3).
Conversion does not add any level of precision, so that number still has single digit precision.
So, 1.000 is valid presentation of 3/2 with whole number precision.
P.S.
Why anybody would need to apply any rounding if the numbers need to be already rounded before passed to rounding function?
_____________
Code for TallyGenerator -
Jacek0, if you read again my posts from the beginning you'll see that I did not try to stop anybody from using BR in accounting where it's required (btw, it's illegal in Australia and NZ).
I objected claims from wiki that BR to be used in scientific or statistical calculations:
When dealing with large sets of scientific or statistical data, where trends
are important, traditional rounding on average biases the data upwards slightly. Over a large set of
data, or when many subsequent rounding operations are performed as in digital signal processing, the
round-to-even rule tends to reduce the total rounding error, with (on average) an equal portion of numbers
rounding up as rounding down. This generally reduces the upwards skewing of the result.
Yes, it's not appropriate in statistics as well, because statistics operate big numbers and numbers coming from calculations to be considered imprecise.
BR assumes the numbers are precise.
In science probability of precise number is exactly zero.
In statistics it's not zero because it does not operate with infinite number of probes. But it applies statistical error on every mentioned number. To make a value more precise you need to increase number of probes. And it decreases the probability of precise number.
Precision will become absolute (you'll get precise number, statistical error will be zero) when number of probes will reach infinity. But here comes zero probability of precise number.
Because BR conception is built on assumption of precise numbers existence it's not a valid method for working with scientific and statistical data.
_____________
Code for TallyGenerator -
I know at least one another person in this thread who thinks .666 is proper representation for 2/3. So, I'm not the only one.
And I know that this representation is considered proper by ASCII, MS (check out your SQL Server) and every person having any clue in math. I mean math, not arith.
Ask any mathematician and he/she will tell you that .666 is proper representation of 2/3 and .667 is not.
.667 is proper rounding result for 2/3, but not representation of not rounded value.
Take any math book and check it out.
_____________
Code for TallyGenerator
Viewing 15 posts - 286 through 300 (of 373 total)
You must be logged in to reply to this topic. Login to reply