June 13, 2007 at 6:01 am
Just to open your eyes that it is not YOU who defines the business rules to follow, for every country in the world.
If some company prefers "Banker's rounding", fine. If some other company prefers another algorithm, fine. If I even bother if I win or loose half a cent some time, I can contact my business partners and ask them which rounding algorithm they use. If I don't like the algorithm they use, I can always change business partner to a partner that uses an algorithm I prefer. But it sounds like a lot of work...
I don't understand why YOU are so stubborn about this?
N 56°04'39.16"
E 12°55'05.25"
June 13, 2007 at 6:14 am
I wonder where did you find I'm so stubborn about this?
Where did I object using of BR is it defined by somebody as a business rule?
> If I don't like the algorithm they use, I can always change business partner to a partner that uses an algorithm I prefer.
Unless you don't have a choice and have to pay to monopolists whatever they ask.
_____________
Code for TallyGenerator
June 13, 2007 at 6:16 am
Feel free to point that person out. .666 is not a good representation for 2/3. .666..., on the other hand, is a wonderful representation for 2/3, as is .6, .6~, and any other method that denotes that the 6 is repeating. If you must round to 3 decimal places, without being able to show that it's repeating, then .667 is the correct representation. Even your beloved Round() function knows that.
After pointing out the other person in this thread, feel free to cite a math book or any mathematician who agrees with you. Since you claim all of them agree, it should be easy, but one of either is plenty. I'll help you out and rule out one cite, which is used to help kids with their homework. It's too bad that they'll all fail since all math books disagree with this website. Okay, here's another one you can rule out. Unfortunately, those children in the New Jersey school system will be learning about repeating numbers by comparing 2/3 to .667, instead of the more correct .666. I certainly hope they're still able to get in college. Damn, another mathbook ruled out. On no, where will it end.
Good luck!
June 13, 2007 at 6:21 am
O M G !!!
Unless you don't have a choice and have to pay to monopolists whatever they ask.
You always have a choice.
N 56°04'39.16"
E 12°55'05.25"
June 13, 2007 at 6:24 am
It did exactly what you asked. Perhaps you should go back and read both what you asked, and what I posted.
June 13, 2007 at 6:28 am
Sorry, David,
I see you're not only bad in math, you're bad in reading.
All your books tell about approximations, roundings, but not representations before rounding.
And your "one cite" cotradicts itself: in calculation it displays 0.666, in final conclusion it displays 0.667.
Guys definitely did not study hard in school.
_____________
Code for TallyGenerator
June 13, 2007 at 6:38 am
You definitely never lived in socialist country.
Go to Cuba or North Korea and tell them about choice.
I believe even Russia or China will be something undiscovered for you.
_____________
Code for TallyGenerator
June 13, 2007 at 6:44 am
You claimed that you did.
But you did not.
I checked the value you supplied - it was 0.66666666.
(2/3) * 3 should be exactly 2.(0)
Right?
Lets' check:
0.66666666 * 3 = 1.99999998
Not as expected.
You failed supply 2/3 to BR function that time.
Can you do it in any way?
I stated BR cannot round 2/3 at all because it works only with precise numbers (according to your explanations).
Can you prove it's wrong?
_____________
Code for TallyGenerator
June 13, 2007 at 8:42 am
"Sorry, David,
I see you're not only bad in math, you're bad in reading."
The irony, it burns.
All your books tell about approximations, roundings, but not representations before rounding.
Rounding is exactly how you represent a shortened version of a number. In other words, they are approximations.
And your "one cite" cotradicts itself: in calculation it displays 0.666, in final conclusion it displays 0.667.
Which cite contradicts itself, while you're at it?
Oh, and who agreed with you again?
June 13, 2007 at 8:46 am
The value I supplied was indeed 2/3. Did you actually read the code?
Yes, 2/3*3 in the environment I ran the tests in does indeed return 2.
Keep digging.
June 13, 2007 at 10:35 am
Ha ha ha ha
If someone living in a socialist country is worrying about rounding functions and the affect on their bank statements then things aren't half as bad as I was led to believe all these years.
I suppose if your honorifics start with "Our glorious leader" then someone using a function you disagree with to calculate how much you've embezzled that day might cheese you off slightly; then again you can always have them executed.
K. (capitalist pig dog)
June 13, 2007 at 2:59 pm
Rounding is exactly how you represent a shortened version of a number. In other words, they are approximations.
Really?
Did you think a second before writing that?
Have you found answers on these questions:
- What kind of representation you supply to FIRST rounding function, which actually gives your beloved rounded representation?
- Why you need to round a value if it must be rounded before to be supplyed to rounding?
> Which cite contradicts itself, while you're at it?
Take a reading course. You've got serious problems. Answer was in my post.
> Oh, and who agreed with you again?
After taking a course take a training in reading and read this topic.
At least one person indicated agreement with my position.
Can give you a hint: it was right after "2/3" thing.
_____________
Code for TallyGenerator
June 13, 2007 at 3:05 pm
What was the datatype of the value you supplied to the function?
Can you show here precise (according to your requirements) representation of 2/3 in that datatype and the way you've got it.
And I'm thrilled to know about environment you were performing your test.
Really.
Because in my environment (SQL2000 Query Analyzer)
select (2./3)*3
returns 1.999998.
_____________
Code for TallyGenerator
June 13, 2007 at 4:57 pm
"After taking a course take a training in reading and read this topic.
At least one person indicated agreement with my position.
Can give you a hint: it was right after "2/3" thing."
Good, then you won't have any problem pointing out who and which post it was in that they said that .666 is the proper representation for 2/3.
June 13, 2007 at 5:06 pm
"And I'm thrilled to know about environment you were performing your test.
Really.
Because in my environment (SQL2000 Query Analyzer)
select (2./3)*3
returns 1.999998."
I told you which environment I ran it in, VB.Net 2003, and posted the exact code I used. Remember, your problem is with the concept of Banker's Rounding, not with the various implementations of it. I demonstrated that Banker's Rounding works perfectly well with 2/3, and correctly returns .67 for 2 digits, .667 for 3 digits, .6667 for 4, etc.
That environment also happily returns 2, when given 2/3 * 3, as you requested.
In other words, the concept of Banker's Rounding performs it flawlessly, and it's not the fault of the function that SQL Server doesn't handle 2/3 properly. Again, since you seem to be sniffing glue or something, a function works with the parameter it receives, not what that value once was somewhere at some time. Period. If a function receives an integer, it's not going to magically know that at one time that integer was actually 1.25986092659036. That has crap to do with Banker's Rounding, but I guess since you haven't made any headway in demonstrating that the concept is wrong, you're going to attack SQL Server's numeric handling, which is something I don't think anyone has ever stated was very good.
If you still take issue with how Banker's Rounding (the concept) handles 2/3, state it explicitly, as the rest of us are well aware that Banker's Rounding will happily hand that number off to the traditional Round function, as it returns the exact same result. So, what is the problem with Banker's Rounding and 2/3?
Viewing 15 posts - 316 through 330 (of 373 total)
You must be logged in to reply to this topic. Login to reply