Round to Even (aka Banker''s Rounding) - The final function
-
Hence the not necessary to do so. But it doesn't stop me from doing it all the time
. -
incredible; 32+pages of Sergiy call everyone wrong-minded for even considering a business concept he doesn't understand/ chooses to ignore...because he wants to argue theory vs reality.
we all know there are some numbers that cannot be expressed accurately. so what.
Sergiy used to be a powerful, helpful voice on this community; lately, it has turned into a Joe Celko like attitude where he treats everyone with comments like RTFM, slams for doing things "the wrong way", insults, and other non-helpful verbiage designed to incite anger and troll for angry back-comments.
I'm truly disappointed. If there was an ignore feature on this board, I would use it , as Sergiy comments no longer seem to be aimed at helping other users. on other boards i frequent, this behavior would merit a suspension of posting privileges.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
Another flamer is going the same way.
"Who are you, Bruno, to tell that the Church is wrong?
Do you mean all Fathers are stupid?"
Can you bring any more intelligent support for BR?
Sometimes it happens when "all these people are stupid".
But sometimes they are just cheating, like that metal trading company.
_____________
Code for TallyGenerator -
Lowell, don't you think it's you who is wrong-minded for considering I ever discussed any business concept here?
I objected mathematical concept of BR. No more.
> we all know there are some numbers that cannot be expressed accurately. so what.
First of all, not "some", but infinite majority. What makes precise numbers not possible event. And makes it all numbers that cannot be expressed accurately.
And that's what makes BR concept based on absolute precision concept to be wrong.
P.S. Can I ask everyone to stop flaming?
If you have nothing to say about BR, don't post.
I know everything about myself. You don't add anything new. Believe me.
_____________
Code for TallyGenerator -
They are both right. It is just an opinion for a point of origin.
You can explain the world and universe having the Earth in centre. The formulas are hideous but it can be done.
However, it is much easier to put sun in the centre. The formulas are easier.
But sun is not in centre. Noone know what is, since the sun is travelling around the milky way in an incredibly speed around, and milky way is travelling around the centre of our universe.
N 56°04'39.16"
E 12°55'05.25" -
Did you want to say "They are both wrong?"
Because BR concept is definitely wrong from math point of view.
I don't see where TR is wrong, but probably you know something I've missed.
> You can explain the world and universe having the Earth in centre.
No one can. All attempts have failed. No formula work without "corrections add-ons". Sorry.
_____________
Code for TallyGenerator -
Hello Sergiy
As for me there is nothing good in not having education essential for the job.
...
I hope you not gonna let this situation stay for long. Best luck to you in that.
Well I've been in IT for 20 years, so my lack of education isn't exactly holding me back. I'm rounding that number of course, but funnily enough both TR and BR return the same, given a factor of a decade.
I could help you with rounding to those freaky bases, but we need to be on common ground first.
What freaky bases? They are all base 10. It's the factor that changes. Even allowing for that faux pas, it's still not freaky. It's a business requirement. That's requirement, not "wouldn't it be nice if..."
Sorry, but "double precision" approach is absolutely unacceptable for BR as it is defined.
Works for me. Though as I've said before... Oh I give up.
Good luck in your career, I hope your co-workers, and future employers read this forum.
Dave J
-
> Works for me.
Really?
Then who was writing this:
Replaced all the float declares with decimal(38,20) but I still get bad results?
Here:
http://qa.sqlservercentral.com/forums/shwmessage.aspx?forumid=8&messageid=370393
Well I've been in IT for 20 years, so my lack of education isn't exactly holding me back.
I better not to comment.
Good side is I always will be in demand because there is a lot of guys around whos lack of education does not hold their IT career.
it's still not freaky. It's a business requirement.
For me it's still freaky.
I do a lot of freaky things every day because they are parts of business requirements (not all of them, actually
)It does not make them less freaky.
_____________
Code for TallyGenerator -
I think I see Sergiy's point, but it seems like arguments from both sides aren't connecting with the other side (it may partially be due to language barriers). The wording of the arguments seems the same, but it's really two different aspects that are being discussed: technical implementation of functions, and real-world accuracy.
Sergiy isn't trying to say that there's anything "special" or "magic" about the internal implementation of the SQL ROUND() function. He is not claiming that when the value .135 is passed to both types of functions that ROUND() programmatically treats the value differently than a BR function does, or that the ROUND() function can somehow represent or work with irrational numbers better.
All he is saying is that the algorithm (not technical implementation) that TR uses takes into account that the value isn't precise better than the BR algorithm, even when you pass a precise decimal into the function. i.e. when you pass the value .135 into either function, the actual real-world value was probably not exactly .135 - for example, the scale might've read out .135 and then someone typed that into a database, but that was just the limitation of the scale that it couldn't show more precision.
So Sergiy is saying that the TR algorithm of the ROUND() function treats .135 as if it is an imprecise measurement of any value between .1350 and .1359 and takes that imprecision into account by always rounding up when the digit is 5, since it's likely that somewhere after the 5 in the real-world value there was a nonzero digit.
It sounds like Sergiy may even agree that BR would be more "fair" if we could be assured that all values passed into a BR function were exact and precise measurements, but he is saying that none of them are, because the "real-world" value that the number represents isn't exactly the value stored in the database or passed into the function.
So arguing based on running values through any function (whether it be BR or TR, in SQL or in .NET or any other language) will not convince either side. It's really a disconnect between whether the person sees the values that are being passed into these functions as 100% accurate measurements of whatever is being measured or not.
This seems to be an ideological or theoretical difference of opinion, not a technical one. Sergiy says that whatever number is stored in the database isn't precise, no matter the data type, and the other side trusts whatever value is stored in the database as the true, accurate value.
Did I accurately sum up both sides?
I must say that the personal attacks don't help either side, though it's probably a result of mounting frustration in not being able to convey the thoughts in a way that can be understood from a common ground.
And if you're wondering whos "side" I'm on, I haven't decided yet. I see why the BR guys would say that it's more fair on large sets, and I see what Sergiy is saying about the imprecision of measured values.
-
We're actually quite aware that his main argument hinges on the imprecision of numbers, and he is even partially correct, in that they often are, but he's wrong when it comes to what that has to do with BR.
The problems with his assertions is that is that there are indeed precise values. 1/8th of a dollar is precisely .125. You can add zeroes to the end if you choose, but it remains .125. By the same token, my piano has precisely 88 keys on it, my Joker-barren deck of cards has precisely 52 cards in it, I have precisely 183.35 dollars on my person, my grocery store paid precisely 5.40 for that 3-pack of Blue Bell Ice Cream gallon cartons to their wholesaler, the interest rate on my mortgage is precisely 5.75%, etc. These are precise numbers.
What are usually imprecise are measurements. I can't tell you my precise height, my precise weight, the precise number of gallons of gas I put in my tank last time I filled up, the precise number of miles I drive to work, nor precisely how loud my stereo is in dbs.
The second problem is that he works on the assumption that all imprecise values are lower than the actual value they represent, using a scale as an example. We'll ignore the fact that he seems to think they work like a stepper motor, clicking over to the next value (in reality, and greatly simplified, they typically rely on multiple strain gages, which simply change resistence when stress is placed on them, and the end result is that tiny differences are measured, and the differences are given values). Well, if that scale says 150.0 lbs., it doesn't mean that the actual weight is higher than 150.0 lbs, but lower than 150.1 lbs. In reality, scales are expected to be within a given range (typically .3%) of their displayed value to be considered accurate. This .3% can be both above and below, so a scale that shows 150.0 is considered accurate if the actual weight is between 149.55 and 150.45. By the same token, if my doctor measures me and come up with 5 feet 10.5 inches, my actual height is just as likely to be 5 feet 10.4 inches as it is to be 5 feet 10.5 inches.
In other words, one, there are precise values, and two, when there are imprecise values, their actual value can be lower than the displayed, stored, known, etc. value as often as it is higher. Therefore, BR is a perfectly valid solution in many situations.
rlively, as a side note, please read the previous thread on this subject if you really want to see the evidence that the BR camp brought forward, as that's where the initial debate started, was thoroughly hashed out, and should have remained.
ETA: Here is a link to the previous thread I mentioned, since it has rolled off the first several pages. It has the tests that were put forth, the code proving that BR passed those tests, all sorts of other evidence, etc. It's truly the best place to start if you're still in the bubble on this issue. By the way, I don't know of anyone on the pro-BR side that is trying to "win" anything. We're just making sure that people are aware that there is a function which they might need at some point in their careers, here's the concept behind the function, here's the supporting data demonstrating that the function performs as desired, and here is how we have currently implemented it, as well as why.
-
The problems with his assertions is that is that there are indeed precise values.
There are no precise decimal numbers.
1/8th of a dollar is precisely .125.
1/8th of a dollar is precisely zero.
1/8th of a $1.00 (with 2 decimal digits precision) is 0.125 with 2 digits precision (last "5" is imprecise and should not be trusted).
1/8th of a $1.0000 (money datatype, 4 decimal digits precision) is 0.1250 with 4 digits precision (no guarantee what are the following digits there).
scale that shows 150.0 is considered accurate if the actual weight is between 149.55 and 150.45.
Wrong again.
It's not how scales work. Talk to professionals and ask them.
And it's not legal.
You can only charge someone for 150.0 lbs if you supplied at least 150.0 lbs. It may be more, not less.
_____________
Code for TallyGenerator -
rlively, while I'd still recommend you read the earlier thread, if you see any claims that you doubt, from anyone on either side of this debate, you should ask for verification. You'll find that the people on the BR side have and will continue to gladly back up any claim that we make. You should ask the same of the other side. For example, Sergiy claimed above "You can only charge someone for 150.0 lbs if you supplied at least 150.0 lbs. It may be more, not less.", which just isn't true, and he won't back it up. While it's true that if the scale says 149.9 pounds, you can't charge them for 150.0 pounds, and you technically can charge them for 150.0 when in fact the scale states 150.1, no one does. People charge based on what the scale says, so now we're down to what are the legal tolerances for a scale, which can be either slightly above, or slightly below 150.0 pounds in our example. If the scale says 150.0 pounds, the law doesn't claim that the weight can't actually be 149.9 pounds. In fact, scale tolerances are measured in a +/- fashion in every state in the U.S, as well as every country with which I'm familiar. That item showing a 150.0 scale reading is just as likely to actually weigh 149.9 as it is to weigh 150.1.
Oh, and to back that up, the NIST is the government agency which oversees our weights and measures regulation here. States are allowed to override it, but they pretty much use the NIST recommendations for tolerances across the board. In case someone doesn't want to look it up, here (PDF file) is what they have to say about tolerances on page 2-30, section T.N.2.1, which is the "General" section under "Tolerance Applications":
"T.N.2.1. General. - The tolerance values are positive (+) and negative (-) with the weighing device adjusted to zero at no load. When tare is in use, the tolerance values are applied from the tare zero reference; the tolerance values apply to certified test loads only."
So, as you can see, there is nothing illegal about charging for 150.0 lbs even if the actual weight is 149.9 lbs, as long as the scale itself displays 150.0 lbs. Feel free to have him back up his side (and while you're at it, a cite that BR is illegal to use in NZ would be great. He won't provide it to us, but maybe you'll get lucky).
If you do go through the effort of reading the other thread, and are convinced after that point that Sergiy is correct, my best suggestion is that you forgo the use of BR, as I'm certainly not a paid spokesperson for the IEEE nor any of the other standards bodies which have adopted it.
I'll happily continue to answer any questions you may have, as well as provide code or cites for any claims I make, as honest debate should be welcome here.
-
David,
start from zero.
If scales show 0.0 lbs it means that actual weight is...
Between -0.1 and +0.1?
Yeah, right.
_____________
Code for TallyGenerator -
rlively, while I'm no longer debating with Sergiy in this thread, as we've already gone over every argument he's ever made, and I've stated that I'm going to stick with only honest debating (which he's shown himself to be incapable of, yet again), this is a good example of what I outlined above.
While I provided a link to a cite from the U.S. government entity which is in charge of federal weights and measures standards, even pointing out the exact text which applies, his rebuttal consists solely of creating a straw man fallacy and a "Yeah, right." If you happen to find both equally credible, then I'm not sure what the point is.
Regarding the straw man fallacy, the actual weight of -0.1 and +0.1 displayed as 0.0 being considered acceptable on a scale is only true if .1 is within the acceptable tolerance, which is why I never made that generic statement. There are scale classes where that would not be acceptable (small postal scales, for example), while there are scales where weights of -25 pounds through +25 pounds would be perfectly acceptable (larger truck scales, for example). The only argument that I made (and that was backed up by the NIST) was that tolerances are acceptable whether they are above or below actual weight.
As noted earlier, read the other thread, and you can see that this pattern is repeated quite often there as well.
-
actual weight of -0.1
Wow, negative masses went into the play...
Dumb goes dumber.
_____________
Code for TallyGenerator
Viewing 15 posts - 316 through 330 (of 377 total)
You must be logged in to reply to this topic. Login to reply