Round to Even (aka Banker''s Rounding) - The final function
-
Sorry, David,
none of them is 1/3.
1/3 does not have exact representation in binary.
And you told that approximate is not good enough.
So, still no answer on my question.
Try again.
_____________
Code for TallyGenerator -
> Why would I care what precision it is? You said BR would not return 2 for that statement.
But you do!
It's you who makes the tales about absolutely precise numbers (in line with other Davids).
It's you who compaining about imprecision of float representation.
And it's you who is using double precision value in the example.
The result "2" is approximate representation of the result, its inacuracy is just a little bit smaller than it can be visible on screen.
It's really easy to check for someone having brains. Just get 2 digits more:
declare @a float
declare @b-2 float
SET @a = 2
SET @b-2 = 3
SELECT @a/@B*@B, @a/@B/100*@B*100
-----------------
2.0 | 1.9999999999999998
No, just like any function, I need to provide BR with what I want it to work with.
So, I want to see how you can provide it with 1/3.
Exactly 0.(3), not any approximation, because, as you said, provide BR with what I want it to work with.
Rounding is supposed to return a different result when the value it receives is .125 than when it receives .1251.
I double thrilled to see how BR can work with 1/3 after this statement.
Because, as you say, it works different when it receives approximate representation of the numnber.
So, bring it on!
Apply BR to 1/3 = 0.(3)!
> I demonstrated a very straightforward method for storing repeating numbers which would work on about any computer out there.
Sorry, it will not work on any computer .
No computer operation supports your fancy datatype.
Can you provide a code to do 1/3+1/7 ?
As I said, you stored decription of building the value, not the value itself.
--------------
And you forgot about Pi again.
You definitely need a medicine.
_____________
Code for TallyGenerator -
This is more stupid than you appear to be. First off, if any programmer actually tried to pass the fraction 1/3 to a function, I'd fire him on the spot. Happens to you a lot, does it?
Secondly, if you BR and traditional rounding will return the exact same results for the same representation of both 1/3 and 2/3, so it's nothing more than some silly sidetrack to hide the fact that you're being moronic. BR only takes effect when, with the number it receives, the digit following the last one to be displayed is a 5, followed by either nothing or all zeroes. That's never ever ever ever ever the case with 1/3 or 2/3, even if you or someone you work with happens to be stupid enough to hardcode those fractions in your rounding code. Did I mention never? As in, you'll both be admitting you are always wrong (which has happened a lot lately, even outside of this thread, so you're not really a stranger to it), as well as evangelizing BR long before 1/3 or 2/3 have anything to do with the concept of Banker's Rounding.
Once again, I'll explain how the concept of Banker's Rounding would return various representations of 1/3, which is dependent on the person passing it, as well as the environment they are working in. In any case, for the various representations, here are the results that IEEE 754 says should be returned by Banker's Rounding
.33 rounded to 1 place = .3
.333 rounded to 2 places = .33
.3333 rounded to 3 places = .333
.67 rounded to 1 place = .7
.667 rounded to 2 places = .67
.6667 rounded to 3 places = .667
Notice a pattern here, or should I point it out.
Oddly enough, the concept of traditional rounding returns the exact same results. The most bizarre part of all of this is that you know this. It is absolutely physically impossible for you to not realize that repeating numbers that don't have a 5 to be found are handled no differently by the concept of Banker's Rounding than they are in the concept of traditional rounding. I don't care how many times you were dropped on your head as a baby, or last week for that matter, we've repeated it over and over again, explained the rules, etc. At this point, I'm soundly convinced that you are lying, obstinate, wrong, and think everyone else who graces these forums is stupid. After seeing some of your other gems in other threads, I'm also soundly convinced that it has nothing to do with this subject, but is just how you are.
I've also used your tests to show that you are wrong, multiple times. At this point, you're not only all of the above, you're also embarassing yourself. A 12 year old peeing himself gets laughed at less than you. I, for one, am starting to enjoy this again, as I've passed the stage of pitying you.
-
> First off, if any programmer actually tried to pass the fraction 1/3 to a function, I'd fire him on the spot. Happens to you a lot, does it?
If a programmer cannot figure out how to process rational numbers I'd fire him on a spot.
0.(3) is a valid number, appears in a lot of cases, and any function must support it.
> Secondly, if you BR and traditional rounding will return the exact same results for the same representation of both 1/3 and 2/3
How do you know?
I never say you supplied 1/3 or 2/3 to BR.
According to your concept it's impossible.
Because BR does not accept approximates, unlike TR.
So, there is nothing to compare.
You pattern may be nice, but there is no answer on my question in it.
BR still cannot work with numbers not having precise decimal representation.
So, go on, keep humiliating yourself.
_____________
Code for TallyGenerator -
Sergiy,
Where did you run the following:
declare
@a float
declare
@b-2 float
SET
@a = 2
SET
@b-2 = 3
SELECT
@a/@b-2*@b-2, @a/@b-2/100*@b-2*100
This was copied directly from your own post.
I ran it in SSMS using SQL Server 2005 x64 Developer Edition and my results are:
---------------------- ----------------------
2 2
(1 row(s) affected)
This was copied directly from your own post.
-
Lynn, which date is correct - the one you're seeing in EM (27/06/2007 11:52) or the one returned by QA (2007-06-27 11:52:15.145) ?
Read about conversion and rounding involved in displaying values in your SSMS and find out why it does not show you the actual thing.
_____________
Code for TallyGenerator -
How about getting off your high horse and answer a straight question with a straight answer. I asked about the environment you ran your test in. I was trying to duplicate it. I can't do that if you are unable, or more likely unwilling, to do that.
-
-
Thank you. Was that so hard?
-
You welcome.
It was implied.
See the forum name on top of this page.
_____________
Code for TallyGenerator -
You could be using SQL Server 7 based on the forum name at top.
-
0.(3) is a valid number, appears in a lot of cases, and any function must support it.
You do know that this directly contradicts the statements you earlier made about computers not being able to handle repeating numbers, right? No, functions don't have to support 0.(3) (why in the world you use this strange notation is beyond me, but we know you have "special" math books), they only support the approximation that they receive as a parameter. They have no clue that it is indeed an approximation of some number that you were working with at one point, or that you'd like for it to be, and simply work with the actual value they get. Period.
How do you know?
Because that is the way the functions are defined. Do you have any hard questions to break up the monotony?
I never say you supplied 1/3 or 2/3 to BR.
Nor do I need to, since I know the rules for both functions. This is kind of stupid, as you have never passed 1/3 or 2/3 (using your bizarre floating definitions of those fractions) to Round() either. You've also never once demonstrated what 1/3 and 2/3 have to do with BR, other than just a boring distraction so that you can try and delay your flameout. Sorry, but it happened about 50 pages ago in the other thread.
According to your concept it's impossible.
No, not impossible, just not important. As long as the approximation of 1/3 or 2/3 (which again, the function itself sees as an actual value, not an approximation) is at least one digit to the right longer than what I want to round to, both rounding methods will return the same value. See, I can actually grasp the rules of the two concepts, and both of them share the same ruleset for how they round the variously precise approximations of 1/3 and 2/3.
Because BR does not accept approximates, unlike TR.
And yet again, TR doesn't accept approximates either in a true sense, as they are no longer approximates once the function has received them as a parameter, just like BR. You can pass it an approximate, but once it has it in its grubby little hands, it's an actual value. If it receives the value .333333, it doesn't think you meant to pass it 1/3, it only knows that it received .333333. It works with an actual, fixed number that it receives, no matter what you want that number to represent. That's how functions work. Everyone here knows that, and you have yet to prove that Round() has some magical knowledge that knows that .333333 was at one time 1/3, or even that it makes assumptions about any of the next digits. It simply follows the ruleset laid out for it. Since I've backed up every single claim I've made in both threads, it's time for you to put up or shut up. Prove that TR has some knowledge about the actual value behind the approximate value. Bated breath and all that...
-
Ran your test code on a server running SQL Server 2000 SP3a using QA:
declare @a float
declare @b-2 float
SET @a = 2
SET @b-2 = 3
SELECT @a/@B*@B, @a/@B/100*@B*100, @a/@B
--- --------------------- ----------------------
2.0 1.9999999999999998 0.66666666666666663
(1 row(s) affected)
I made one change, I added @a/@B to the query. Obviously SQL Server 2000 and SQL Server 2005 handle these a little differently so Sergiy, your test doesn't prove you right or wrong, just that computer systems are not perfect.
Things can change between implementations, so we have to deal with it as appropriate for our users.
-
You do know that this directly contradicts the statements you earlier made about computers not being able to handle repeating numbers, right?
Not right.
It does not contradict to anything I said.
Because you can supply to any computer function limited number of representations of unlimited number of actual values any function must be built on mathematical assumption that the number supplied is not absolutely precise. It actually represents not only itself but any other value close enough to be within the inaccuracy limit.
Hope it did not burn fuses in your head.
Grab some beer, chill it out and try to read it again.
Eventually you suppose to get it.
At least some kids in school do, so there is some hope.
> No, not impossible, just not important.
You still failed to provide an example of supplying 1/3 to your function.
So, I still can consider it's impossible.
And because this value is very popular it's very important.
> you have never passed 1/3 or 2/3 ... to Round() either.
No, I did.
I can supply to the function 4 digits precise number 0.3333 which (by mathematical model used for TR) represents all values between 0.3333(0) and 0.3333(9). 1/3 is within this range, so it's included and processed.
Function returns result common for every number within this range and it accepts any value within this range.
> And yet again, TR doesn't accept approximates either in a true sense, as they are no longer approximates once the function has received them as a parameter, just like BR.
TR does accept approximates. Because it treats 0.1250 as one in the range of values having this number as a representation: any value from 0.1250(0) to 0.125(9).
And because any of these values is > 0.1250 (remember, probability of precise equation is zero) TR rounds it up.
0.1250 (say, using money datatype) supplied to TR loses all values between 0.1250(0) and 0.125(9) and takes into consideration only impossible case of absolute equation.
And because this case is impossible the result of BR is 100% wrong.
That's why BR was failing for 5/111.111 - result of this calculation just does not have enough precision.
Sorry, but in real life you cannot always control the precision of numbers your function gets. Adding "implied" zeros does not fix anything, you don't always know what are the digits beyond precision, so adding anything is mathematically incorrect.
_____________
Code for TallyGenerator -
I can supply to the function 4 digits precise number 0.3333 which (by mathematical model used for TR) represents all values between 0.3333(0) and 0.3333(9). 1/3 is within this range, so it's included and processed.
Yay, the magic function again. I'm glad you brought this up, since this is what you continue to claim, and have yet to provide proof for. As noted earlier, it's time to put up or shut up. Prove that TR sees the precise number 0.3333 as all values between 0.3333(0) and 0.3333(9).
Viewing 15 posts - 211 through 225 (of 377 total)
You must be logged in to reply to this topic. Login to reply