Round to Even (aka Banker''s Rounding) - The final function
-
You really need to learn to be professional. Name calling is not good form. I am fully aware of mathematics, and you haven't provided a single mathematical proof in any of these threads.
You refuse to admit when you may be wrong, or admit that others may have an actual point that may just be right.
Nothing you have said as won many of us over to your point of view, and some of that can easily be due to your condesending attitute toward opinions that are different from yours. You jump to name calling abd berating people and making fun of their accomplishments. You obviously don't want to make many friends or influce people very much, or you would learn to tone down the rhetoric.
This battle will never be won, by either side, and you take it as a phyrric victory, as I personally have had enough and will not bother arguing these points with you further.
-
Lynn, you are really funny guy!
You really need to learn to be professional. Name calling is not good form.
Was it about yourself?
Because it's you who introduced name calling into the discussion.
I am fully aware of mathematics, and you haven't provided a single mathematical proof in any of these threads.
I'd like to see any example of mathematical proof in your understanding.
Is there any?
You refuse to admit when you may be wrong, or admit that others may have an actual point that may just be right.
Golden words!
Right about the reason of your denial of all mathematical prrofs!
Nothing you have said as won many of us over to your point of view
Not many.
Neutral watchers already admitted that your side is wrong.
You jump to name calling abd berating people and making fun of their accomplishments. You obviously don't want to make many friends or influce people very much, or you would learn to tone down the rhetoric.
Not everyone is like yourself.
Some people may be different.
But I don't want have idiots amongst my friends. I don't like idiots.
This battle will never be won, by either side,
That's exactly what people say when they don't want to admit their defeat.
I personally have had enough and will not bother arguing these points with you further.
AGAIN???
5th, 7th time?
This was funny last time, now it's ludicrous.
_____________
Code for TallyGenerator -
Sergiy,
I guess with that 4 bit computer I shot myself in the foot because we were not able to go through some reasonable rounding exercises that would allow us to get closer to why Round can always be applied and always works and BR sometimes cannot be applied, i.e. I want to see all the bits of the number for which BR cannot be applied. It might also get us closer to understand how Round makes use of 0.66(0) and 0.66(9). Thus I'm going to try with a 10 bit computer representing numbers between 0 and <1. This lets me represent numbers to an accuracy of 3 decimal places making rounding to 2 decimal places mathematically valid. You do agree that what is true regarding rounding for a 32 or 64 bit computer is true also for a 10 bit computer.
I seem to remember that we had fun with 2.0/3.0.
1010101001 0.665039
1010101010 0.666016
When I do
set @n=0.66666666666666666666666666666666666666
or set @n=2.0/3.0
it gets stored as 0.665039 and Round(@n,2) returns 0.67 and BR(@n,2) returns 0.67
When I say 'returns 0.67' from the Round or BR function I refer to the 10-bit stored value 0.669922. For displaying a number to 2 decimal places normal rounding is always used (even if the number was generated with the BR function).
We also played with 50.0/111.111
0111001100 0.449219
0111001101 0.450195
When I do
set @n=0.45000045000045000045000045000450004500
or set @n=50.0/111.111
it gets stored as 0.449219 and Round(@n,2) returns 0.45 and BR(@n,2) returns 0.45
We need to look at some of those fortunate numbers that can be represented precisely:
0010000000 0.125000 Round(@n,2) returns 0.13 and BR(@n,2) returns 0.12
0110000000 0.375000 Round(@n,2) returns 0.38 and BR(@n,2) returns 0.38
1010000000 0.625000 Round(@n,2) returns 0.63 and BR(@n,2) returns 0.62
1110000000 0.875000 Round(@n,2) returns 0.88 and BR(@n,2) returns 0.88
These are also useful to look at (i.e. it's like the 5 followed by loads of zeros - even if it's only one - followed by a non-zero digit):
0010101001 0.165039 Round(@n,2) returns 0.17 and BR(@n,2) returns 0.17
0110101001 0.415039 Round(@n,2) returns 0.42 and BR(@n,2) returns 0.42
So now I browsed a bit through these 1024 numbers and I must say I'm having difficulty finding a number for which BR cannot be correctly applied.
Sergiy, can you help? Remember, I'm a three year old kid.
-
Lynn, it passed the million random values test just fine, as well as performing Sergiy's ".0000 to .1999 step .0001" test flawlessly, just like David J's function. It's looking good on negative number handling, etc. It's likely good to go.
-
Michael,
does you computer support only 1024 values between 0 and 1?
I tell you, there are much more.
Infinitely more.
Limited precision (in you example - very limited precision
) does not allow to show them precisely, but you must represent them somehow with available numbers and make sure you make your rounding correctly.And remember - you must be extremely lucky to get precise value stored in your computer. You need much more luck for this than for winning jack-pot every week in every lottery during a year.
Because there are only 1024 precise values and infinite number of imprecise. So, your chances to get precise number are 1024/infinity = 0%.
Let's take any value not from your 1024 lucky ones.
For example, the value 1001.0/8000.0 does not have exacts representation in your computer. It will end up there as 0.125 (don't include rubbish into you examples, due to step 1/1024 you have only 3 decimal digits, all others are useless).
BR returns 0.12 for this number despite it represents value which is > 0.125. It's an error.
TR returns 0.13, and that's right.
BR will return wrong results for all similar values: 1002./8000, 1003./8000, up to 1007./8000.
For 1008./8000 results of BR and TR will be the same, so both are correct now.
Do you see the numbers where BR fails?
Fine.
From another side, if we run 1000./8001 on your computer it will end up with 0.124 representation, and both roundings will round it down. No errors here.
About you last example.
You went out of your computer scope.
Its precision level is limited to 3 digits, so you just cannot display 0.165039 or 0.415039. You must have cheated, used another computer, with better precision, to get those numbers.
Your computer will have only 0.165 and 0.415. All following digits are not trustful and should not be taken into consideration for any kind of operations on those numbers.
I'm afraid, BR will make some errors here as well.
_____________
Code for TallyGenerator -
Sergiy,
You are cheating a bit
, i.e. you are doing arithmetic using numbers to 4 digit accuracy whereas all we got is 3 ditigt accuracy. With 101.0/800.0, 102.0/800.0, etc. all seems to work fine, e.g. 101.0/800.0=0.126 which Round and BR round to 0.13.Maybe we should say that 1001.0/8000.0 cannot be represented 'accurately enough' in a 10 bit computer. And there is no point to round something you cannot represent 'accurately enough'. If I want to handle rounding of 1001.0/8000.0 I need a computer with just a few more bits to handle 4 digit accuracy and where BR would handle it just find.
Thus I would be curious if you can find an operation using 3 digit numbers or show me a 3 digit number which cannot be rounded correctly using my 10 bit computer.
As for 0.165039 I should really have said 0.1650390625. It's obtained using the binary number
0.0010101001
and the following weights (summing the asterisked values gives you the above number - accurate to 10 decimal places - what a lucky guy)
01 0.5000000000
02 0.2500000000
03 0.1250000000*
04 0.0625000000
05 0.0312500000*
06 0.0156250000
07 0.0078125000*
08 0.0039062500
09 0.0019531250
10 0.0009765625*
Thus the binary number 0.0010101001 is an exact representation of the number 0.165039062500000... - even though we only use 0.165. And yes, with 10 bits there are only 1024 such lucky numbers. Everything else falls between the cracks.
And yes, I used a 32 bit computer to do all that arithmetic. But that's not cheating.
-
I'm not cheating.
Those numbers are numbers from real world.
Which come to your computer to be stored with 3 digits precision.
Point is - even with so poor precision your computer can manage return right rounding result of real world numbers (which it cannot even handle!) if it uses TR, and fails to do it if it uses BR.
_____________
Code for TallyGenerator -
OK, I will give you 4 more bits to play with. Thus 1001.0/8000.0 sits between
0.00100000000010 0.1251220703125000
and
0.00100000000011 0.1251831054687500
Thus we are dealing with 0.1251 which BR rounds perfectly to 0.13.
Of course you are now going to hit me with 10001.0/80000.0 and we now know what we need to do to make BR work properly even for this one. And when we run out of bits then we are trying to do something unreasonable because the value you are trying to store cannot be stored 'accurately enough'.
So can we come to the conclusion that BR will always work if the number is represented 'accurately enough'?
If you agree with that I will try to make a formal definition of 'accurately enough'. Somehow this feels right to me.
-
There are no numbers represented "accurately enough".
Between every "precise" value represented "accurately enough" there are infinitely many "imprecise" values which cannot be represented "accurately enough" with any decimal reprecsentation, with any precision.
You may add as many bits as you want, you'll never reach infinity.
The chance you've got from real world the value which absolutely equal to its decimal representation is 1/infinity = 0 (zero)%.
Mathematics and Statistics name it "impossible event". Because such event has zero chance to happen.
Impossible events should not be taken into consideration for any assumptions.
THat means, with 100% probablity (translation - absolutely for sure) real value represented by a decimal number is NEVER EQUAL TO ITS REPRESENTATION.
You can happily come to the conclusion that BR will always work if the number is represented 'accurately enough'. I would even agree with this.
The problem is there are no such numbers.
So, BR always works for not existing values.
Quite useful tool, don't you think?
_____________
Code for TallyGenerator -
Yes, yes, Sergiy - we know all that - it's great stuff.
There are no numbers represented 'accurately enough'.
Although I thought we had agreed that 0.125 was represented exactly by 0.0010000000 - on my 10 bit computer. We'll let that go for the moment.
In any case, we need to concentrate: on my 10 bit computer (I regret ever having given you a peek at my 14 bit computer). Because so far you have not come up with a case where BR to 2 decimal places gets it wrong on my 10 bit computer. And your case of 1001.0/8000.0 is not a valid proof. Because when you 'execute' (in Query Analyzer?) something like that on my 10 bit computer or you compile a program with something like that on my 10 bit computer you get an error message saying: "Cannot store 1001.0 or 8000.0 with the 10 bits I got (much less do arithmetic with it). Try again."
On my 10 bit computer, you can do things like 0.005/0.111 which gets you 0.045045045...(between you and me) and is stored as 0.0000101110 (0.044921875) which, if displayed, will show 0.045 and for which Round to 2 decimal places returns 0.04? (because all it 'sees' is 0.044921875?) and BR returns 0.04? (because all it 'sees' is 0.044921875?) - on my 10 bit computer.
But how is 0.005/0.111 (which between you and me is 0.045045045...) really 'seen' by Round and BR on my 10 bit computer? If my 10 bit computer limits you to 3 decimal places (via its 10 bit architecture) and if we are doing decimal rounding, does that mean that 0.0000101110 (0.044921875) is really 'seen/interpreted' as 0.045 and thus Round returns 0.05 and BR returns 0.04?
So show me a valid number or a valid operation on my 10 bit computer which causes BR to get it wrong. And if so, what does it see that causes it to go wrong?
Sergiy, I hope you understand why I prefer to use a 10 bit computer for this problem. It lets you see things close up. It lets you see - close up - the edge on the right hand side where things start getting strange and fuzzy. It lets you see the bits - without going dizzy. It lets you talk about the problem using numbers that are manageable and that can be seen - not just by you and me but also by my 10 bit computer.
-
Michael,
please READ AND UNDERSTAND my previous post.
Please READ AND UNDERSTAND.
I did not reference any number of bits in it.
Because it does not matter.
How many numbers between 0 and 1 in your computer?
Any way it's limited quantity?
And how many numbers between 0 and 1 in real world?
Infinity.
So, I don't care about numbers in your computer, because it cannot store even simple 2/3.
I need to get proper rounding of the real world numbers on any computer I've got.
And TR mathematical model allows me to do it even on 8 bit computer, but BR mathematical model fails and on 64 bit.
P.S. There is an error in your 0.005/0.111 example.
Read about the way computer processes numeric data and the way it converts result into DECIMAL representations.
_____________
Code for TallyGenerator -
So you think the problem with BR cannot be demonstrated with my 10 bit computer?
-
It can.
If you'll figure out where is a place for 2/3 in your computer.
_____________
Code for TallyGenerator -
I took another look at 0.005/0.111 which, you said, was wrong. If I reason in a certain way (especially in regards to what BR sees/receives) then it can actually be used to show that BR gets it wrong.
The number 0.045045045... sits between these two
0000101110 0.045
0000101111 0.046
which means the first one gets used.
Thus what BR in my 10 bit computer receives and sees is 0.045 (not the 0.044921875 full expansion I see) which it rounds to 0.04 which is not the same as BR of 0.045045045... which should be rounded to 0.05.
Thus BR can definitely get it wrong and we have pretty much concluded that a while ago.
But I'm curious how often it gets it wrong in real world usage. Thus if we deal with random numbers accurate to 6 decimal places and do BR rounding to 2 decimal places then you really have little to worry about. The only time BR gets it wrong is if the 3rd digit is a 5 and the 4th, 5th and 6th digits are zeroes and because of precision error there is something after the 6th decimal place that got lost. The number of numbers that can be represented between 0 and <1 to 6 decimal places is 1 million. Of these numbers, the ones that are problematic are numbers like 0.125000, 0.575000, etc. These occur exactly 200 times. So the chance for BR to get it wrong in this scenario when dealing with random numbers between 0 and <1 is about 1 in 5000.
And if you use even more precision then chances becomes quite remote (1 in a billion?) for BR to get it wrong.
Have I got this right?
Even looking at typical numbers banks deal with, say $5680.27, on which it has to calculate (to say 16 decimal places) 11.25% interest and then do BR to 2 decimal places. The chance that it gets this sort of calculation wrong on 1 million bank accounts is practically zero.
Have I got this right?
-
> But I'm curious how often it gets it wrong in real world usage.
Every time BR returns not the same result as TR.
You did not answer: is there a place in your 10 bit computer for 2/3?
_____________
Code for TallyGenerator
Viewing 15 posts - 136 through 150 (of 378 total)
You must be logged in to reply to this topic. Login to reply