

SSC Veteran
Group: General Forum Members
Last Login: Monday, July 22, 2013 1:05 AM
Points: 248,
Visits: 373


Comments posted to this topic are about the item Predict output for ROUND function
KSB  Thousands of candles can be lit from a single candle, and the life of the candle will not be shortened. Knowledge and happiness never decreases by being shared.”  Buddha




Hall of Fame
Group: General Forum Members
Last Login: Saturday, June 6, 2015 9:44 PM
Points: 3,448,
Visits: 4,408


If I change the variables to anything from float(25) to float(53), I get the wrong answer (75.42) What's the relation between this value and the values from the question (165.755, 165.555)?!
If i use flat(24) or less, I get the correct answer. Ok, let's use float(24). The result is: 165.76, 165.55. Is this result correct?
There's no way to get a correct answer without cheating (copypasteexecute) or making a guess Oh, except this one: you should know SQL Server internal binary representation of floats (which is undocumented and may vary from version to version)...




SSChasing Mays
Group: General Forum Members
Last Login: Friday, January 11, 2013 12:41 PM
Points: 621,
Visits: 297


Does the explanation for the question has any relation with the output of the code?
I think this question has nothing to do with your SQL Server Knowledge.
Bhavesh Patel
http://bhaveshgpatel.wordpress.com/




SSCAddicted
Group: General Forum Members
Last Login: Sunday, November 2, 2014 9:13 AM
Points: 488,
Visits: 338


I realized that the poster had cutpaste from the link he has included in the answer. This could have been avoided by careful proofreading; It might have been a case of oversight.
However I am not clear what exactly the question is testing here? How is it that the rounding behaves differently for two very similar numbers?
When I use float(24) for I get 165.76 in the first select > implying rounding behaves as expected. When I use float(25) I get 165.75 > implying there is no rouding; rounding does not behave as expected.
In the second select statement  the situation is reversed: Now when I use float(24), I get the result  165.55 implying no rounding. When I use float(25)  I get 165.56  implying rounding happens as expected.
So when a double byte precision is used for 165.755  no rounding happens; When double byte precision is used for 165.555 rounding does happen.
What is so drastically different between these two numbers that's causing the difference in behavior?
Does any one know?
Saurabh Dwivedy ___________________________________________________________
My Blog: http://tinyurl.com/dwivedys
For better, quicker answers, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537
Be Happy!




Ten Centuries
Group: General Forum Members
Last Login: Wednesday, November 18, 2015 4:12 PM
Points: 1,360,
Visits: 7,238


Seemingly random behavior with a random explanation. Could someone provide a valid explanation?
bc




Right there with Babe
Group: General Forum Members
Last Login: Tuesday, December 7, 2010 12:55 AM
Points: 771,
Visits: 504


I don't have an explanation, but I did do some testing and learned that the same error occurs with .255, .355, .755, and .855, but does not occur for .055, .155, .455, .555, .655, and .955.
I don't know if it's truncating the float at some point or not, but this is good to know if you need to do calculations and rounding using floats.




SSCrazy
Group: General Forum Members
Last Login: Sunday, November 22, 2015 8:03 AM
Points: 2,909,
Visits: 1,322


The "rounding" differences are actually taking place when the numbers are stored as real and float approximate numbers. These are IEEE standard formats, they are in fact documented. You can look at the binary values with this query:
SELECT F24, ROUND(F24, 2), CAST(F24 AS VARBINARY(8)), F25, ROUND(F25, 2), CAST(F25 AS VARBINARY(8)) FROM (SELECT CAST(165.755 AS FLOAT(24)) AS F24, CAST(165.755 AS FLOAT(25)) AS F25) x FLOAT(1) through FLOAT(24) is stored as 4byte singleprecision floating point, or REAL. FLOAT(25) through FLOAT(53) is stored as 8byte doubleprecision floating point.
The 8byte version is 0x4064B828F5C28F5C. 406 is the sign bit and exponent, 4B828F5C28F5C is the mantissa. (There are 53 mantissa bits but the leading bit is always 1 and not stored, so the next 52 bits are shown as 13 hex digits). The exact value would be 4B828F5C28F5C28F5C (with 28F5C repeating forever), but it has to stop and round at the 13th character. The 54th bit of the mantissa is 0, so the remainder is discarded and what is stored is something like 165.754999999999. This rounding occurs as the characters "165.755" are converted to FLOAT, the ROUND() function comes later.
The 4byte version is 0x4325C148. The sign bit and exponent take 9 bits (43 plus part of the 2), so the mantissa looks different from above because it is shifted one bit. If you divide 4B828F5C28F5C (followed by 28F5C forever) by 2 (or convert to binary, tack a extra 0 on the front, and regroup the bits into hex digits) you get 25C147AD147AD (followed by 147AD forever). When this is rounded off after 24 bits, the remainder starts with a 1 bit so the final 7 is rounded up to 8. You end up with roughly 165.75501.
So the ROUND() function is not rounding the exact value 165.755 in either case. With singleprecision it is rounding something slightly larger and with double precision it is rounding something slightly smaller.




Ten Centuries
Group: General Forum Members
Last Login: Wednesday, November 18, 2015 4:12 PM
Points: 1,360,
Visits: 7,238





SSCoach
Group: General Forum Members
Last Login: Wednesday, November 11, 2015 12:39 PM
Points: 19,343,
Visits: 17,687





Right there with Babe
Group: General Forum Members
Last Login: Friday, October 23, 2015 11:26 AM
Points: 721,
Visits: 715


Great explanation Scott, that's very detailed and instructive. Unfortunately it does not address the behavior found by KevinC. Why is not the behavior you describe consistent in a given range of numbers?
Dan



