Round to Even (aka Banker''s Rounding) - The final function
-
BR, by definition, is NOT meant to get the same results as TR. And the fact that 2/3 doesn't have a precise place in my 10 bit computer doesn't change that definition.
Thus my conclusion:
1. Yes BR can get it wrong because of information loss when numbers are represented in computers.
2. For what and how BR is used in the real world, it gets it wrong very rarely, in fact, with probability around zero.
-
Sorry to remind you, but you still failed to answer the question:
Is there place for values 2/3, 1/9, 4/7 and, if yes, where is it?
> BR is used in the real world, it gets it wrong very rarely
Once again, EVERY TIME it's different from TR.
Yes, it's very rarely when it's different, but every time it is it's wrong.
_____________
Code for TallyGenerator -
Yes, it's very rarely when it's different, but every time it is it's wrong.
That's what I wanted to hear. And 'every time' is very rarely, i.e. probability around zero.
-
So, what's the point to use BR if every time it is different from TR it's wrong?
Would it be more logical to use rounding which is right every time, even in very rare cases?
_____________
Code for TallyGenerator -
BR is defined differently from TR. That's why it produces different results. I, who have chosen BR instead of TR, want it that way because I like the definition of BR and what its purpose is.
-
Yes, BR is defined differently, and its definition of BR is wrong.
It returns wrong results every time it's different from TR by definition.
_____________
Code for TallyGenerator -
But thinking more, I'm coming back to your side and I'm, in fact, questioning the need for BR.
Thus, it gets it wrong with a low level of probability because the special definition part of BR actually gets applied very rarely.
Going back to my example of 1 million numbers from 0 to <1 accurate to 6 decimal places, for most numbers BR and TR do the same thing. But for 0.125000 it's different. If this were exactly 0.125000 then BR's special definition would produce the correct result of 0.12. But most of the time (especially when derived from calculations) it is really something else and thus BR gets it wrong because of lack of decimal precision.
Mmmhhh, I'm starting to not like BR very much...
I'm even losing faith in its concept of 'fairness' that BR was said to have over TR.
Thus when dealing with large numbers of calculations where you get 0.125000, the chance that it is exactly 0.125000 and not zillions of variants like 0.1250001, 0.12500011, etc. is practically zero. Thus for those 100 numbers out of the 1 million BR gets it wrong half the time. So here we have 100 numbers intended especially for BR's special handling and it gets it wrong half the time with probability close to zero. The other half of the times it gets the same result as TR (e.g. 0.135000 - precise or not - becomes 0.14)
So what's the point of BR?
Sergiy, maybe you have finally won me over.
-
It's not me.
It's math.
Good for you, you did not forget it completely, and I needed just remind you some important things.
Unfortunately, not everyone here is that lucky.
And what is more unfortunate (for all of us) those people are allowed to do programming.
_____________
Code for TallyGenerator -
Bankers Rounding does not get it wrong
Bankers Rounding will round correctly any number given to it according to the rules of Bankers Rounding specified
Bankers Rounding will produce different results to other rounding methods because it is different, even other types of rounding can produce different result for the same number
Bankers Rounding is a valid rounding technique if the business and system that uses it deems it to be, just because you do not like it, does not make it wrong
1.23 is numerically equivalent to 1.230000 one is neither more or less than the other, basic math.
Far away is close at hand in the images of elsewhere.
Anon. -
David, there are no numbers "exactly half way" as BR specified.
Read previous page.
Pay attention to the part where I explain why it's not possible to have a value equal to its numeric representation.
BR rounds numeric representations, not real values represented by decimal number.
That's why BR cannot round 2/3, because there is no way to supply 2/3 to BR - there is no decimal number which is equal to 2/3.
And if you admit that 0.666666 could be a valid representation for 0.666666(6) you cannot find any strong reason why 0.125000 could not be a valid representation for 0.125000(6). Or 0.125000(123), or 0.125000(1).
Which all must be rounded up. Not like BR prescribes.
I don't have anything personal against BR.
It's just mathematically wrong.
And quote from Wiki sayng that BR is valid and recommended method for statistical and scientific calculations makes me worry about situation with eduaction in America.
It's terrible there is nobody in Wiki community who would know such bacis things.
1.23 is numerically equivalent to 1.230000 one is neither more or less than the other, basic math.
Don't make you look more stupid than you are.
0.33 is equivalent of what: 0.3333333 or 0.3300000?
And what is 1/3 in computer world?
Do computers any mean to store and operate imprecise relational numbers?
You really need to look at basic math handbook one day.
_____________
Code for TallyGenerator -
BR rounds numeric representations, not real values represented by decimal number.
BR rounds numbers
That's why BR cannot round 2/3
BR works with numbers not fractions
because there is no way to supply 2/3 to BR
0.666666 is a valid decimal representation of 2/3 and that can be passed to BR
And if you admit that 0.666666 could be a valid representation for 0.666666(6)
0.666666 is a valid rounded representation of 0.666666(6)
Which all must be rounded up.
In traditional rounding true but BR is not traditional rounding
I don't have anything personal against BR.
Me neither and I would resist it's use personally but if a business deems is valid then that is their perogative
Don't make you look more stupid than you are.
So you are saying 1.23 minus 1.230000 is non zero?
p.s. That is your standard and predictable crass and asinine reply and it makes you the one that looks stupid
Far away is close at hand in the images of elsewhere.
Anon. -
In traditional rounding true but BR is not traditional rounding
Not true.
Did you read definition of BR?
It says if ALL following digits are zeros.
Problem is you don't know the ALL following digits.
You can see only digits within precision.
Following digits could be any ones.
And only in case when by occasion all digits beyond are (0) BR works as defined.
But mathematic say it's impossible event.
That's why with 100% probability 0.125000 must be rounded up even according to BR definition.
0.666666 is a valid rounded representation of 0.666666(6)
Really?
Are you serious?
Would you check it with a math teacher in nearest elementary school?
And what's a point to round something already rounded?
So you are saying 1.23 minus 1.230000 is non zero?
What are the precisions of those numbers?
And what do you mean when say "zero"?
If it means zero with absolute precision: 0.(0) then answer is "No".
If it means zero with precision of least precise value: 0.00 then answer is "Yes".
Problem is in math 0.00 is not equal to 0.(0).
It's equal with 2 digits precision.
But it's probably too overwhelming for simple minds.
_____________
Code for TallyGenerator -
It says if ALL following digits are zeros.
The following zeroes are implied
1.23 is 1.23, trailing zeroes are implied but not shown
Problem is you don't know the ALL following digits.
You can see only digits within precision.
Following digits could be any ones.
Nope. 1.23 has trailing zeroes, no more no less
And only in case when by occasion all digits beyond are (0) BR works as defined.
As I stated before, BR will work correctly to it's definition on the number passed to it. It is the number's accuracy that may give erroneous results not BR.
Would you check it with a math teacher in nearest elementary school?
I did and he said "You used "Symmetric Rounding Down"
And before you say it, yes it can lead to rounding errors.
And what's a point to round something already rounded?
Agree but then sometimes it may be required. Any form of computation may lead to some rounding.
So you are saying 1.23 minus 1.230000 is non zero?
Comparison in math, the least precise number' precision is increased and therefore
1.23 will be implicitly converted to 1.230000 and then compared with 1.230000, therefore they are equal and equivalent
(the same goes for subtraction)
Far away is close at hand in the images of elsewhere.
Anon. -
> The following zeroes are implied
Implied by whom?
Can you give any reference to any math rule which implies those zeros?
> Comparison in math, the least precise number' precision is increased and therefore
I see, you definitely were not performing well in school.
The rule of math is strictly opposite.
And there is a good reason for this.
DECLARE @One float
DECLARE @Three float
DECLARE @OneThirdDecimal DECIMAL(12,6)
DECLARE @OneThirdFloat float
SET @One = 1
SET @Three = 3
SET @OneThirdDecimal = @One/@Three
SET @OneThirdFloat = @One/@Three
SELECT @OneThirdDecimal - @OneThirdFloat as Zero
----------------------
Final SELECT returns differens between 2 identical values measured with different precision.
It's zero. Zero by definition.
Zero with precision of least precision you have in calculation.
Think about it.
If you still remember how.
To help you with this process I can suggest to return final result in an expression having that "least precision":
CONVERT(decimal(12,6), @OneThirdDecimal - @OneThirdFloat)
What do you see?
Desired zero?
Right.
Just don't forget about those trailing digits you just saw in the same (THE SAME!) number expressed with greater precision.
They were not zeros.
So, zeros are not implied.
It's a fact - followins digits are not zeros.
_____________
Code for TallyGenerator -
Can you give any reference to any math rule which implies those zeros?
No.
But if 1.23 expressed to 6 decimal places is 1.230000, then, if the trailing zeros are not implied what are they?
Where did float come from, I was discussing decimal numbers and not even in a computing context
Your example uses float and decimal, everyone knows that conversion from float to decimal is inaccurate
change all the dataypes to float or decimal and see what the results are
Far away is close at hand in the images of elsewhere.
Anon.
Viewing 15 posts - 151 through 165 (of 377 total)
You must be logged in to reply to this topic. Login to reply