Bankers Rounding
-
a function works with the parameter it receives, not what that value once was somewhere at some time. Period.
And you cannot pass 2/3 to the function.
You cannot do it in any computer system. Using any computer language.
Every time you are trying to pass 2/3 you end up with passing truncated representation of this value. Truncated to the last precise digit.
Normal ROUND function takes it into consideration. It assumes that 0.666 with 3 precise numbers could represent anything between 0.666(0) and 0.666(9). Including 0.666(6).
And 0.125 with 3 precise digits can represent anything between 0.125(0) and 0.125(9).
That's why there are no problems with passing 2/3 to TR function.
It just comes in appropriate representation correlated to the chosen data type.
BR assumes that 0.666 with 3 precise is 0.666(0) and only 0.666(0).
And 0.125 with 3 precise digits can represent 0.125(0) and only 0.125(0).
That's why you can never pass 2/3 to this function.
There is no any DECIMAL or FLOAT value precisely representing 2/3
It just cannot get there.
Never.
_____________
Code for TallyGenerator -
"And you cannot pass 2/3 to the function.
You cannot do it in any computer system. Using any computer language."
Then explain to me how I was able to perform the calculation "2/3 * 3" and end up with "2", which you claimed wouldn't happen.
"Normal ROUND function takes it into consideration. It assumes that 0.666 with 3 precise numbers could represent anything between 0.666(0) and 0.666(9). Including 0.666(6)."
It makes no such assumption. It simply follows the rule of traditional rounding (next digit 5 or more, round up, next digit 4 or less, round down). If it truly thought it could represent any of those, then it would round all ten of those possibilities to .666. It doesn't. It ain't magic, Einstein.
"And 0.125 with 3 precise digits can represent anything between 0.125(0) and 0.125(9)."
This is as true as your last statement, i.e. not at all. Traditional rounding will happily let 0.125 be a 3 digit precision representation of .1245 through .12549..., but nothing higher. If it thought that it represented .1259, it would happily display .126.
"That's why there are no problems with passing 2/3 to TR function."
There are no problem passing 2/3 to BR either, as I happily demonstrated, and you continue to pretend didn't happen. Both TR and BR will happily display .67, .667, .667, .6667, .66667, etc., depending on how many digits you want to see. That's because both BR and TR follow the same rule for numbers ending in 6, which 2/3 does no matter how far to the right you go.
"BR assumes that 0.666 with 3 precise is 0.666(0) and only 0.666(0)."
Finally, an accurate statement, but of course TR makes the exact same assumption, which is why if you pass it .666 and round to 4 digits, it remains .666. If you pass .666 (which is obviously not the same thing as 2/3) to BR, it will also see it as .6660, so they both see it in the same way.
"That's why you can never pass 2/3 to this function."
I did pass 2/3 to a Banker's Round function, and even posted the code and the environment, so it would be repeatable. Would someone out there please run this for Sergiy, and validate the results? While you're at it, please run the other code I posted demonstrating that 2/3 * 3 does indeed return "2" in the same environment.
"There is no any DECIMAL or FLOAT value precisely representing 2/3"
Yay, two correct statements in a single post. That should up your average of correct statements per post in this thread to .012, which is of course an approximation. Of course, no one is arguing otherwise, and you've been using that fact to trash the Banker's Rounding concept, which has nothing to do with it. In fact, I'll happily admit that VB does a bit of trickery behind the scenes to pull off the above code, with an assumption on my part that there are certain tolerances at which point VB assumes it's dealing with repeated numbers (alternatively, it could use an internal flag to denote repeating digits, which would make it spot on in this case), and accounts for that. I don't have the Framework source, so no way to verify what method it uses for certain, but it certainly does produce the correct results to your test, and we both know (as well as everyone else in the world) that computers and infinitely long repeating numbers don't mix very well. So, you are indeed correct (unless they do use a flag of some sort), but you're preaching to the choir.
Still, none of that, and I do mean none of it, has anything to do with either the positives or negatives of the banker's rounding concept.
Feel free to actually find a problem with banker's rounding. I'll give you a little hint. Since you're a big fan of traditional rounding, then the only difference, and therefore the only area for complaint is that banker's rounding handles 5, followed by no non-zero digits, differently from traditional rounding. That's it. Every other complaint you have applies to traditional rounding as well as banker's rounding. So, if you wish to continue, stick to that one specific difference, as that is all there is. The very first post in this thread documents that fact in its comments.
-
> Then explain to me how I was able to perform the calculation "2/3 * 3" and end up with "2", which you claimed wouldn't happen.
For those who did not perform well in school I explain:
"/" and "*" have the same priority. So, it may be executed in any order.
If you write 2/3*3 it does not mean that division will be done first.
To enforce the order you need to specify it:
SELECT (2./3) * 3
I actually wrote this several posts ago.
But your difficulties with reading probably did not let you get it.
"There is no any DECIMAL or FLOAT value precisely representing 2/3"
Yay, two correct statements in a single post.
Actually every statement in my post is correct.
But we'll leave it.
What is important that you admitted that 2/3 cannot be represented precisely with DECIMAL or FLOAT value.
This leads us to a conclusion:
Because BR function accepts only precise DECIMAL (or FLOAT) values imprecise value "2/3" cannot be passed to this function.
How many times I need to repeat it to make you follow the logic?
_____________
Code for TallyGenerator -
> If you pass .666 (which is obviously not the same thing as 2/3) to BR,
So, what I need to pass to pass 2/3?
Which value accepted by BR function will be the same as 2/3?
_____________
Code for TallyGenerator -
environment = SQL2000 Query Analyzer
select (cast(2 as float)/ cast(3 as float)) * 3
Result
2.0
-
You don't use float in your function.
Right?
Because it's imprecise.
So, please use datatypes you're using for your function.
_____________
Code for TallyGenerator -
Float is the best datatype for calculations because it provides the most precise outcome.
In that example error brought by float calculations is less than float precision - 15 digits.
It does not mean there is no error.
Make it a little bit more demanding:
select CAST((cast(2.22 as float)/ cast(3.33 as float))as float) * cast(3.33 as float)
Result: 2.2200000000000002
Here we are.
Error was just in next digit. 17th one.
Add another digit - you'll see bigger error.
You function requires (30,20) precision.
Not good enough.
_____________
Code for TallyGenerator -
Your changing the rules again.
So, please use datatypes you're using for your function.
OK.
select (cast(2 as double precision)/ cast(3 as double precision)) * 3
Dave
-
Isn't double precision a synonym of float?
Do you use actually use double precision in the function?
Did your mama tell you not to lie?
_____________
Code for TallyGenerator -
And I don't change any rules.
I just try to make you follow your own rules.
Was it you who told about precise numbers to be supplied to BR?
No?
Did you support this rule?
So, why you now ditch it?
Or should I bring here errors produced by BR using FLOAT?
THey are right in this topic, page 2.
_____________
Code for TallyGenerator -
Isn't double precision a synonym of float?
So I believe.
Do you use actually use double precision in the function?
Yes. Proof once again you do not read these posts carefully. Go on, have a look at the latest version posted to the 'other' thread. Which you have responded to.
Did your mama tell you not to lie?
But of course. She also taught me to be polite.
Dave J
-
"For those who did not perform well in school I explain:
"/" and "*" have the same priority. So, it may be executed in any order.
If you write 2/3*3 it does not mean that division will be done first.
To enforce the order you need to specify it:
SELECT (2./3) * 3"
For those playing along with the home version of the game "Make Sergiy look like a fool"...
Please run the statement "Debug.Write((2 / 3) * 3)" in the aforementioned environment. I'll give you a hint. He's performing well in the titular role of this game.
Dave J, at this point this is no longer like shooting fish in a barrel. The fish have taken the guns, put them in their mouths, and pulled the trigger. We really need a high-five smiley.
-
I think by the time this argument is finished the IEEE 754 standard will probably be changed...
-
I read it carefully.
Especially this:
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=8&messageid=370393&p=5
What made you change datatype of the input parameter?
Don't remember?
Read the topic from the beginning and refresh your memory.
FLOAT version did not work. And it still does not work.
You posted examples of wrong results by yourself.
Decimal function does not work as well. Examples posted by me.
One of them - 50/111.111.
This function does not work in any way.
Because you cannot build right thing based on the wrong concept.
_____________
Code for TallyGenerator -
David,
simple question:
Do you supply precise values to BR function?
Yes or no?
Does this function accept imprecise input parameters?
Yes or no?
If yes - which way do you use to supply imprecise parameters using precise datatypes?
If no - how can you use this function for rounding imprecise values if you cannot pass it to the function by definituin?
_____________
Code for TallyGenerator
Viewing 15 posts - 331 through 345 (of 373 total)
You must be logged in to reply to this topic. Login to reply