Recent PostsRecent Posts Popular TopicsPopular Topics
 Home Search Members Calendar Who's On

 Scaled-down SQL Rate Topic Display Mode Topic Options
Author
 Message
 Posted Tuesday, March 22, 2011 8:47 AM
 Ten Centuries Group: General Forum Members Last Login: Thursday, January 24, 2013 9:59 PM Points: 1,354, Visits: 1,299
 SanDroid (3/22/2011)Great question. You would not believe how long and how often programers get this wrong. There is even a list that is maintained of ROM chips that do weight conversions incorrectly becuase Dec(6,2) is used instead of Dec(13,5)I even had to "show the math" on this exact thing a year ago when I had to explain why the weight conversion code used to change Pound to Kilos and vice versa was wrong in every appliation where I work. Not understanding this math is why so many ships have a problem balancing thier loads.Sometimes the cargo is weighed in pounds and the balast program uses Kilos.Then someone uses a cheap hand calculator to convert the 100,000 tons in pounds to Kilos and the weghts off by at least 1,000 tons.Are you sure that extra weight isn't from the stowaways (Illegal aliens) that are aboard and unaccounted for?Besides, isn't counting ballast by kilo's easier? One kilo of weight and one liter of water displacement equals neutral buoyancy. Doing that in another factor is 2.2 pounds for each 0.26417205263729593 (approx) US gallons of displacement.
Post #1082033
 Posted Tuesday, March 22, 2011 9:15 AM
 Ten Centuries Group: General Forum Members Last Login: Thursday, January 31, 2013 8:01 AM Points: 1,232, Visits: 1,046
 cengland0 (3/22/2011)[quote]SanDroid (3/22/2011)Besides, isn't counting ballast by kilo's easier? One kilo of weight and one liter of water displacement equals neutral buoyancy. Doing that in another factor is 2.2 pounds for each 0.26417205263729593 (approx) US gallons of displacement.I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out... That you know why we use Kilo's in the Balast programs?
Post #1082053
 Posted Tuesday, March 22, 2011 11:43 AM
 Ten Centuries Group: General Forum Members Last Login: Thursday, January 24, 2013 9:59 PM Points: 1,354, Visits: 1,299
 SanDroid (3/22/2011)I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out... That you know why we use Kilo's in the Balast programs?Just that I would never use pounds in the formula. Also, when speaking of Tons, you have the metric ton which is 1000 kilograms and that is about 2205 pounds. Most people assume ton as a "short ton" which is 2000 pounds. As you can see, there's a couple hundred pounds difference between the two so it might not be a conversion issue but an assumed unit problem.
Post #1082194
 Posted Saturday, March 26, 2011 9:19 AM
 SSCertifiable Group: General Forum Members Last Login: Today @ 12:20 PM Points: 7,931, Visits: 8,348
 cengland0 (3/22/2011)SanDroid (3/22/2011)I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out... That you know why we use Kilo's in the Balast programs?Just that I would never use pounds in the formula. Also, when speaking of Tons, you have the metric ton which is 1000 kilograms and that is about 2205 pounds. Most people assume ton as a "short ton" which is 2000 pounds. As you can see, there's a couple hundred pounds difference between the two so it might not be a conversion issue but an assumed unit problem.I've heard of short tons before, but never seen a case where they have been used (maybe that's because I don't live where people do USA measures). A metric ton (tonne) is 1000kg, and a long ton is 2240lb, so the difference between the two commonly used tons is only about 1.5%, not the 10% difference between the short ton and the tonne or the 12% difference between the short ton and the long ton. This means that the error mentioned (something over 1000 tons in 100000, so a bit over 1%) is far too big to have been cause by confusing short tons and metric tonnes and although it's about the right size for confusing metric tonnes and long tons that seems very unlikely to me because Sandroid wrote explicitly about conversion from pounds to kilograms, so it really is rounding error not terminological confusion. Tom'S iomadh doigh a th’ air cu a mharbhadh gun a thachdadh le ìme
Post #1084447
 Posted Friday, April 01, 2011 12:16 AM
 SSC Eights! Group: General Forum Members Last Login: Friday, November 08, 2013 4:21 PM Points: 924, Visits: 334
 Interesting question and a great explanation.I learned something, although i got it wrong :)!
Post #1087249
 Posted Wednesday, May 25, 2011 1:09 AM
 SSCrazy Group: General Forum Members Last Login: Wednesday, November 20, 2013 5:16 AM Points: 2,345, Visits: 492
 michael.kaufmann (3/21/2011)tilew-948340 (3/20/2011)I am sorry, but I realy, realy don't understand why D is not good, even if I do your formula. Why is so that D would have a truncate answer and not C? I mean, both have a precision of 51 and only the scale is different (3 more digit more for C), which might explain something if you could explain my question here:If I declare D as precision of 23 instead of 25 and still having a scale of 10DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)it is still a precision over 38, and the scale is still 20 as previous, but the answer is not truncateWhy??? First of all a great big thank you to Duncan for this excellent QotD and the explanation.Whether the decimal result is 'truncated' or not is a mere mathematical question:D would result in precision 51 and scale 20; in order to not truncate the integer part of the numeral, SQL Server does the following:- maximum precision = 38, desired precision is 51 ==> 51 - 38 = 13- since it doesn't truncate the integer part, the decimal portion (scale) is truncated: 20 - 13 = 7.Hence the result for option D is DECIMAL(38,7).If you use a precsion of 23, the math is as follows:- Precision: 47 - 38 = 9- Scale: 20 - 9 = 11- Result: DECIMAL(38,11)However, as Duncan stated in his explanation, scale will never be less than 6; so the 'minimum' result in regards to scale will always be DECIMAL (38,6).Regards,MichaelNice question! And this is an excellent explanation. /Håkan WintherMCITP:Database Developer 2008MCTS: SQL Server 2008, Implementation and Maintenance
Post #1114539
 Posted Sunday, June 26, 2011 4:40 AM
 SSChampion Group: General Forum Members Last Login: Today @ 12:00 PM Points: 11,052, Visits: 10,810
 Duncan Pryde (3/20/2011)bitbucket-25253 (3/20/2011)Excellent question and a more than excellent explanation of why the correct answer is what it is.Thanks - high praise indeed! I must mention though, that when trying to decide how to format the explanation, I came across this excellent post from SQL Kiwi (Paul White?) - which helped me considerably to come up with a clearer and more concise one than I would have done otherwise.Yes, that's me. Paul WhiteSQL Server MVPSQLblog.com@SQL_Kiwi
Post #1131755

 Permissions