June 12, 2007 at 12:09 am
> Banker's rounding doesn't return "false results" any more than any other method of rounding or truncating a number, it returns perfectly predictable results which may or may not fit the business purpose at hand.
For example:
select 100000000.01/800000000.01, dbo.fn_BRound( 100000000.01/800000000.01 , 100), Round( 100000000.01/800000000.01 , 2)
---------------------------------------
.12500000001093.1200.13000000000000
_____________
Code for TallyGenerator
June 12, 2007 at 12:29 am
For any representation of 2/3 you'd like to use, Banker's rounding will return the same results as Round().
June 12, 2007 at 12:42 am
That's not a problem with banker's rounding, but with the implementation of it that you are using. Even the OP which launched this thread has a definition that meets the proper criteria. I'll repost it here so you don't have to go back to the first page. As you can see, .12500000001093 will round up to .13 using banker's rounding, if implemented properly.
* Decide which is the last digit to keep.
* Increase it by 1 if the next digit is 6 or more, or a 5 followed by one or more non-zero digits.
* Leave it the same if the next digit is 4 or less
* Otherwise, all that follows the last digit is a 5 and possibly trailing zeroes;
then change the last digit to the nearest even digit. That is, increase the rounded
digit if it is currently odd; leave it if it is already even.
If you'd like to debate the accuracy of the function being used, that would be a wonderful direction to take, as I think everyone would benefit from a version that matches the standard method of implementation, but your argument has been against the concept, not the implementation, as was clear by the second page.
June 12, 2007 at 3:01 am
It's not a question of which representation I'd like to use.
Bankers Rounding just cannot process 2/3 at all.
What's a problem for you to show the code where you round 2/3 using BR?
Need some help from professionals?
_____________
Code for TallyGenerator
June 12, 2007 at 3:56 am
> If you'd like to debate the accuracy of the function being used, that would be a wonderful direction to take, as I think everyone would benefit from a version that matches the standard method of implementation, but your argument has been against the concept, not the implementation, as was clear by the second page.
Did you actually read my posts here?
I brought all proofs why THE CONCEPT IS WRONG.
You just did not want to listen.
Your argument was - it works for actual numbers, and nothung else matters.
Bring my code where it does not work.
Now I brought you examples where it does not work for actual numbers.
And you are blaming the function implementation.
So, improve the function, increase it's precision - and I'll add 1 digit to the precision you've set and it will fail again.
THERE IS ALWAYS NEXT DIGIT!!!
So I can always come up with numbers proving that function is wrong.
ALWAYS.
That means only one thing - conception if this function is wrong.
The error in this conception - is an assumption about absolute precision of the numbers rounded. Assomption, that all digits after the last presented digits are zeros. Zero period.
This is wrong.
You saw how 2/3 was presented. It was trancation to the last precise digit. 8th diigit in that case. It does not mean that 9th digit is 0. You know that it's not true.
The same story for every other number.
Every decimal number you see is a truncation of another number with better precision.
You know only digits presented and cannot tell anything about the following digits. It could be anything. It could be zero, but could be 1, 2, ... 9.
But with 100% probability you can say it's not zero period.
And rounding must take it into consideration.
BR does not do it - that's why it's wrong.
P.S.
BTW, BR is not approved as a general practice in Australia, New Zealand, in some European countries which accounting practices I'm aware of.
Does anybody know any country where BR is an acceptable practice outside USA?
_____________
Code for TallyGenerator
June 12, 2007 at 6:24 am
DECLARE
@enumerator decimal(23,15)
,@denominator decimal(23,15)
SELECT
@enumerator = 2
,@denominator = 3
SELECT
dbo.fn_BRound(@enumerator/@denominator, 100)
,Round(@enumerator/@denominator,2)
As I stated earlier, it ends in a 7, just as it should.
June 12, 2007 at 6:35 am
DECLARE
@enumerator decimal(23,15)
,@denominator decimal(23,15)
SELECT
@enumerator = 2
,@denominator = 3
SELECT @enumerator/@denominator,
dbo.fn_BRound(@enumerator/@denominator, 100)
,Round(@enumerator/@denominator,2)
---------------------------------------- --------------------- ----------------------------------------
.666666666666666 .6700 .670000000000000
Still rounding truncated value, not 2/3.
You stated in this topic that truncated value is not the same as non-truncated.
So, you failed to rounf 2/3.
Try again.
_____________
Code for TallyGenerator
June 12, 2007 at 6:37 am
You've actually brought zero proof as to why the concept is wrong.
"You just did not want to listen."
The irony, it burns.
"Your argument was - it works for actual numbers, and nothung else matters."
Um, its job is to work for actual numbers. It's not supposed to work with letters. It's not supposed to cure cancer, etc.
"Bring my code where it does not work."
I'm supposed to bring your code where banker's rounding doesn't work? Wouldn't that be your job?
"Now I brought you examples where it does not work for actual numbers.
And you are blaming the function implementation."
That's correct, and for a very good reason. The implementation doesn't match the functional specifications of banker's rounding. Why would I blame the concept for a function that doesn't implement the concept properly? The concept is laid out in the very first post in this thread, and is what you disagree with.
So, improve the function, increase it's precision - and I'll add 1 digit to the precision you've set and it will fail again.
"THERE IS ALWAYS NEXT DIGIT!!!
So I can always come up with numbers proving that function is wrong.
ALWAYS."
And banker's rounding will always take that next digit into account. Always. If any of the next digits are non-zero, they are counted and affect rounding. Did you read the quote from the first post?
The rest of your stuff looks like your typical "1/8 of 8 isn't 1" gobbledy-gook, so I'll skip it, except for your question about countries where banker's rounding is acceptable.
Banker's rounding is acceptable in all countries as far as we know, and unless you can show us where it is illegal for a person to use banker's rounding, if it fits their purposes, it will remain so. If you're looking for a country that requires banker's rounding, on the other hand, you'll likely be looking for a long time. It's a rounding method that can be used by anyone whose needs it meets.
June 12, 2007 at 6:43 am
Everytime I think of any type of rounding ISFA money is concerned, I keep thinking of that wonderfully silly movie called "Office Space"... if you haven't seen it, go rent it... make sure you have your favorite beverage while watching.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2007 at 6:45 am
David, BR does not take into account next digits.
It assumes that all digits following those you can see (depending on precision you've got) are zeros.
Which is an impossible event.
That's why it's wrong. Always.
_____________
Code for TallyGenerator
June 12, 2007 at 6:45 am
PC Load Letter? WTF does that mean?
-- Cory
June 12, 2007 at 6:47 am
"Still rounding truncated value, not 2/3.
You stated in this topic that truncated value is not the same as non-truncated.
So, you failed to rounf 2/3."
Are you seriously blaming banker's rounding on the fact that computers don't represent .666... properly in a decimal data type? Banker's rounding and traditional rounding both return .7 when rounding 2/3 to 1 decimal place, return .67 when rounding 2/3 to two decimal places, .667 when rounding to three decimal places, .6667 when rounding to four decimal places, etc.
Forrest, "reeding r gud", but I'll repeat it again for you. Banker's rounding only differs from traditional rounding when the digit to the right of the last "display" digit is a 5 AND there are no non-zero digits after that. 2/3 does not meet this criteria, and therefore does not differ from traditional rounding when applied to that number.
June 12, 2007 at 6:53 am
If you have a next digit, it takes it into account. If you don't have a next digit, it doesn't. It's a function, and like all functions, it works with whatever is passed to it. If you want the number .197156063245902356091265 passed to it, then pass that. If you pass it just .197, it will work on that. Whatever a function receives is what it has to work with. If the computer has a flaw that passes it the wrong number, it will work on the wrong number. If the datatype used has a limitation, it will work with the results of that limitation, just as any other function does. Banker's rounding isn't magic, remember.
Rocket science it ain't.
June 12, 2007 at 6:55 am
June 12, 2007 at 7:19 am
I already did and posted the code.
Viewing 15 posts - 256 through 270 (of 373 total)
You must be logged in to reply to this topic. Login to reply