Bankers Rounding
-
Still waiting on that code, by the way.
-
If you are agree what is the point of the argument then?
If there are no precise numbers - then there are no "not rounded numbers". Every number is rounded because of its imprecise nature.
I stated it from the very beginning:
because there are no precise numbers we need just agree how we treat the expression we use to name "precise" - as a beginning of the following range or an end of the previous one.
Lynn suggested that it is beginning. I was agree and you did not object (as well as anybody else).
Then, if 0.125 is a precise expression of imprecise values which are >= 0.125 - it must be rounded up. It will bring less inaccuracy that rounding down.
TR does rounding up.
BR does rounding down.
Conclusion: TR is more precise then BR.
Always.
_____________
Code for TallyGenerator -
Once again:
it's a professional forum. We are discussing not me or you, we discussing Bankers Rounding.
Try to behave as a professional.
_____________
Code for TallyGenerator -
When in the world did I ever say there are no "precise" numbers? There are "precise" numbers, using many of the different definitions of "precise", including mathematical definitions. You are the one claiming otherwise.
TR does indeed round up, and BR does indeed round down. TR also rounds down, and BR also rounds up. I hope that didn't shock you too much. The difference is when the result is "precisely" halfway between two valid numbers, based on the desired precision, TR only rounds up, while BR will round up about half of the time, and down about half of the time, when given a large, randomly distributed sample size.
Still waiting on that code. Should we get some SQL person to assist you, since you seem to be having trouble putting it together?
-
David, do you actually understand the stuff you are writing about?
What does it mean:
the result is "precisely" halfway between two valid numbers, based on the desired precision
?
It's good you used quotes because result cannot be precise if there is precision specified.
Precision defines the level of acceptable inaccuracy. If you've got non-zero level of inaccuracy - your number is non-precise by definiton.
And your inaccuracy is definitely not zero: no matter how many digits you put in your number - infinite number of digits is still missing to reach zero inaccuracy.
So, you number is inaccurate within desired precision.
But could it be actually equal to the precise number indicated by stored value?
Let's see. There is only one value within the precision interval absolutely equal to the indicated value. And there is infinite number of values greater than indicated value. Probability of equasion = 1/infinity = 0.
So, it's impossible to have actual value to be equal to the precise value indicated. With 100% probability we can say that actual value is greater than its representation.
It's 100% probability that value represented by "0.125" is > 0.125 and < 0.126.
Now, if you worry about "large, randomly distributed sample size" divide interval [0..1) to 100 equal parts:
[0.00-0.01), [0.01-0.02), .., [0.49-0.50), [0.05-0.51), .., [0.99-1.00)
and tell me how many of them will get values in it rounded down and how many will get numbers rounded up.
After that you may answer how you's round values 0.1252, 0.1257 and how you should round two "0.125"'s representing the same values if you don't have enough precision to hold 4th digit.
I believe it should be the same way. Because values are the same.
Do you?
P.S. In any doubt please refresh in memory the question about midnight event.
_____________
Code for TallyGenerator -
Infinity! From "why does this algorithm return inconsistant results?" to Infinity. And beyond!
It is known that there is an infinite number of worlds, simply because there is an infinite amount of space for them to be in. However, not every one of them is inhabited. Therefore, there must be a finite number of inhabited worlds. Any finite number divided by infinity is as near to nothing as makes no odds, so the average population of all the planets in the universe can be said to be zero. From this it follows that the population of the universe is also zero, and that any people you may meet from time to time are merely the product of a deranged imagination.
- Douglas Adams
Who imagined Sergiy?
Dave J
-
Of course I do, as does everyone else in this thread, save for you. A result can absolutely be precise even if there is precision specified. You might be be aware that it is precise, there might be no way to determine, based on the value stored, whether it is precise, but it can nevertheless be precise. 1/8th of the integer 1 is precisely .125, no matter how many zeroes you want to tack onto the end of it. When dealing with quantities, 1 is precise, whether you want to call it 1, 1.0, 1.000, or even 1.000..., as is 2, etc. Yesterday at the store, I received precisely $1.78 in change after my purchase, even though the tax itself wasn't precisely calculated. If the currency used in my country had coins that represented a thousandth of a dollar, I might have received a different amount, but that doesn't change the fact that my change was indeed, precisely $1.78.
On the other hand, that makes no difference whatsoever. The goal of any rounding function isn't to reach precision, it's to allow numbers to be represented by a smaller precision than may be required, for various reasons. Some of those numbers won't require rounding, and will remain identical after the rounding process, some will change due to the rounding process. The goal of banker's rounding is to reduce the bias that this process inevitably introduces.
Still waiting on that code. It should be a piece of cake to prove us all wrong, and I've even offered to find someone to help you write it, as I did myself the last time you thought you had proof. Is it just taking you a while to come up with a proof that doesn't backfire on you like the last one?
-
He also said:
Cyberspace is - or can be - a good, friendly and egalitarian place to meet.
- Douglas Adams
and
Don't believe anything you read on the net. Except this. Well, including this, I suppose.
- Douglas Adams
and even more ironically:
I don't believe it. Prove it to me and I still won't believe it.
- Douglas Adams
-
Heh... I like it! Simple math... everything in the universe ultimately rounds to zero... with or without bankers rounding!
(Unless you're gonna round up, eh?)--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) -
> 1/8th of the integer 1 is precisely .125, no matter how many zeroes you want to tack onto the end of it.
Are you sure 1/8 = 0.125?
Try this: SELECT 1/8
What you've got?
Right, 0.
Because there are no fractions in world of quantities.
Any opration on values expressed in precise natural numbers will bring you the same kind of result - natural number.
To get 0.125 you need to convert quantity to imprecise number 1.0 or 1.00 or 1.000000000000000E0
What is the precision of such conversion?
Well, it depends on the precision specified for the result value.
If you specify "1." it will be "real" precision, if you specify "1.000000000000000" it will be "float" precision.
But anyway, you're not dealing with precise quantities anymore, you're dealing with some imprecise measuremens.
There is no 1.0 of you (could it be 1.1 of you?). It could be 1.0 of you mass, your weight, etc. But not 1.0 of you.
So, precision of 0.125 depends on precisions of 1., precision of 8. and precision of .125 stored.
And it's not precise because neither of those values is specified with absolute precision.
That's why you don't have right to assume all following digits in 0.125 are zeros. You just don't know that.
And if you'll return to my previous post you'll see that with 100% probability 0.125 > 0.125(0)
_____________
Code for TallyGenerator -
"If on the cell with an elephant you see the label "Hyppo" - don't believe your eyes".
The name of this author will not say you anything.
_____________
Code for TallyGenerator -
Still no code. Having problems?
-
As I see you have nothing to say anymore for defence of BR.
_____________
Code for TallyGenerator -
No problem:
Declare @a Decimal(10, 3)
Declare @b-2 Decimal(10, 4)
SET @a = 0.1253
SET @b-2 = 0.1253
SELECT Round(@A, 2), dbo.fn_BRound(@A, 100)
SELECT Round(@B, 2), dbo.fn_BRound(@B, 100)
_____________
Code for TallyGenerator -
Which part of the statement: "The only criteria is that it include a large, randomly distributed data sample set, and that it demonstrates that traditional bias has less (or even equal, since I'm nice like that) bias than the convergent rounding function." are you having trouble understanding? All of it?
Let's check your test:
Large data set? Nope.
Randomly distributed data set? Nope.
This last test of your's is the stupidest response in this thread so far, and that's not an easy milestone to reach.
You know what's even funnier than the stupidity of that test? The fact that even though you cherry picked the hell out of it, it still shows banker's rounding is far better.
Traditional rounding returns results totaling .26, while the banker's rounding method returns .25. The unrounded number is .2506. So, banker's rounding is .0006 off, while the traditional method is .0094 off, almost a factor of 16. I'm not sure if this is the point where we go from mocking you to pitying you, but we're sure getting close.
Viewing 15 posts - 196 through 210 (of 373 total)
You must be logged in to reply to this topic. Login to reply