Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345

Scaled-down SQL Expand / Collapse
Author
Message
Posted Tuesday, March 22, 2011 8:47 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen 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

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, January 31, 2013 8:01 AM
Points: 1,228, 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

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen 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

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 10:21 AM
Points: 7,747, Visits: 9,495
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
Post #1084447
Posted Friday, April 1, 2011 12:16 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, August 18, 2014 6:13 AM
Points: 984, Visits: 350
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

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:38 AM
Points: 2,582, Visits: 553
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 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
MCSE: Data Platform
Post #1114539
Posted Sunday, June 26, 2011 4:40 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Monday, September 29, 2014 10:07 PM
Points: 9,926, Visits: 11,183
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 White
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #1131755
« Prev Topic | Next Topic »

Add to briefcase «««12345

Permissions Expand / Collapse