

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.




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?




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.




SSCrazy Eights
Group: General Forum Members
Last Login: Yesterday @ 10:00 AM
Points: 8,551,
Visits: 9,043


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




SSC Eights!
Group: General Forum Members
Last Login: Friday, July 11, 2014 1:49 AM
Points: 968,
Visits: 349


Interesting question and a great explanation. I learned something, although i got it wrong :)!




SSCrazy
Group: General Forum Members
Last Login: Thursday, July 3, 2014 2:45 AM
Points: 2,531,
Visits: 536


michael.kaufmann (3/21/2011)
tilew948340 (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 10 DECLARE @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 truncate Why??? 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, Michael
Nice question! And this is an excellent explanation.
/Håkan Winther MCITP:Database Developer 2008 MCTS: SQL Server 2008, Implementation and Maintenance




SSChampion
Group: General Forum Members
Last Login: Today @ 1:36 AM
Points: 11,192,
Visits: 11,091


Duncan Pryde (3/20/2011)
bitbucket25253 (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 White SQL Server MVP SQLblog.com @SQL_Kiwi



