Round to Even (aka Banker''s Rounding) - The final function
-
But it was your statement that decimal 0.3333 is not equal to 1/3 and cannot represent 1/3 for BR purposes.
Not mine
So, what is your way to supply 1/3 to BR function?
As a decimal with at least the precision of the input datatype
If you would listen to your math teacher in school you would know that correct rounding to Nth digit requires (N+1)th digit to be available and precise.
True, if there is no (N+1)th digit, no rounding takes place and the input is returned
So, your example just illustrates your ignorance (take a note - I did not say stupidity), and nothing else.
What has rounding to do with subtraction
And will you answer my storekeeper question, please
Please tell me how the storekeeper got the result of (int) 1 minus (decimal) 0.33 = 0.67 to give you change of 67 cents
Fortunately, my computer handles imprecise values correctly, according to mathematical model using fixing precisions.
And while we are at it, I am also interested in how your computer handles imprecise values correctly, can you explain how.
Far away is close at hand in the images of elsewhere.
Anon. -
Sorry, it was yours.
So, what is your way to supply 1/3 to BR function?
As a decimal with at least the precision of the input datatype
Which is correct representation of 1/3:
money = 0.3333
or
DECIMAL(12,6) = 0.333333
Remember, one of them is incorrect, according to you, because 1/3 - 1/3 = 0
And 0.3333 - 0.333333 = -0.000033.
I said that -0.000033 = 0 with 4 digits precision.
But you objected.
When you were wrong?
And what are implied digits in money value 0.3333?
_____________
Code for TallyGenerator -
-
Still no proof to back up your absurd claims?
-
By the way, since I don't actually expect for you to ever back up any of your claims, I decided to continue to code your own stuff for you, as in the past it's proven you wrong over and over again. On the other hand, you did make one claim which has some validity, even though you didn't code it. When you stated...
"BR rounds 0.1251 stored with 4 digits precision UP and stored with 3 digits precision DOWN.
Sorry, but it's an error.
Any function must return consistent result independent from precision supplied value was measured with."
You are indeed correct, and I do find that a bit problematic about the function, even though it is simply following its rules.
Since you didn't provide any code, I did it to see if that was problematic, and indeed BR returns 2 different values when rounding to 2 decimal places, 1 for the original value, and a different one for the original value when BR rounds it to 3 digits first. TR, on the other hand, returns the same 2 digit approximation for the original value as it does for the original value when TR rounds it to 3 digits first.
Is this your main beef with BR, as I can see that it has some merit?
Code follows:
DECLARE
@ThreeDigitValue
decimal(38,20)
,@FourDigitValue decimal(38,20)
-- Set the starting value
SET
@FourDigitValue = .1251
-- Round it to 3 digits, using the same function that we'll use to round to 2
SET
@ThreeDigitValue = dbo.fn_BRoundLynn(@FourDigitValue,3)
-- Round both to 2 digits, comparing the results
SELECT
FourDigits
= dbo.fn_BRound(@FourDigitValue,2)
,ThreeDigits = dbo.fn_BRound(@ThreeDigitValue,2)
-- Now we'll let Round() play
-- Round it to 3 digits, using the same function that we'll use to round it to 2
SET
@ThreeDigitValue = Round(@FourDigitValue,3)
-- Round both to 2 digits, comparing the results
SELECT
FourDigits
= Round(@FourDigitValue,2)
,ThreeDigits = Round(@ThreeDigitValue,2)
-
Third time.
Especially for idiots.
1) The way TR rounds 0.1250 shows that it takes 0.1250 as > 0.1250(0);
2) The way TR rounds 0.1249 shows that it takes 0.1249 as 0.1250(0) but #.####(0) and < #.####(9);
5) Number 0.3333 fits the format specified above, so it will be treated the same way. As a value between 0.3333(0) and 0.3333(9).
Not sure idiots can understand logical proof.
Will see now.
_____________
Code for TallyGenerator -
While none of your five points are actually true, and you haven't provided proof for any of them, I still am willing to give you some credit for that one issue I outlined above in code. If that's your beef with BR, I'm warming up to it, but your silly tangents aren't helping. So, is that your beef with BR?
-
-
No, TR takes 0.1250 as = 0.1250. What it does with it afterwards is based on its rules, and determined by how many digits you want to round to, but if passed 0.1250, it simply sees 0.1250, just like the Round function does.
-
And you still haven't responded as to whether the above coded issue is your main beef with BR. Until you tell us, I have no clue where you are coming from, and simply see silly, unrelated questions raised on a continuous basis. As soon as we swat one down, you toss up something else, without ever explaining in a coherent manner what it has to do with the issue. It would be like me responding to your posts with "But, can you prove the hole in your wall isn't made with cheese? Huh, can you? Did you eat it?". So, what exactly are your beefs with BR, if not that .1251 issue above, which admittedly, is a bit odd looking.
-
No, TR takes 0.1250 as = 0.1250.
Can you provide any proof for this?
-----------
There is no such value as 0.1250.
0.1250 is a limited precision decimal representation of some value.
Because this representation inaccurate it may represent unlimited number of values.
And you never know which one this time.
What TR does is based on mathematical interpretation of this representation.
According to the concept TR is based on.
_____________
Code for TallyGenerator -
"No, TR takes 0.1250 as = 0.1250.
Can you provide any proof for this?"
Absolutely, but not really in the mood to do so since you haven't answered any of my questions that I've been posing to you. Feel free to change that.
-
So, no proof to back up your absurd claims?
_____________
Code for TallyGenerator -
Let's finish with one question before we move to next ones.
_____________
Code for TallyGenerator -
Tons of proof, which I've repeatedly brought to the table. Hell, I even proved that you were correct in how BR handled .1251. Still waiting on the answers to my questions, which were asked first.
Viewing 15 posts - 241 through 255 (of 378 total)
You must be logged in to reply to this topic. Login to reply