>>kg = 1 kg
>>gram = 0.001 kg
>>pound (Avoirdupois) = 0.453592 kg
>>pound (Germany) = 0.5 kg
>>ton = 1000 kg (also known as "metric ton")
>>ton (US) = 907.2 kg
>>short ton (US) = 1016 kg
>>solar mass = 1.988e30 kg (often used for comparisons in astronomy)
>>
>>Now, to convert, say, from "ton" to "ton (US)", you would look both up in a table, check that they both convert to the same base units, in this case kg (it makes no sense to convert kilogram to meters, or square meters to meters, though this is a frequent question in online forums...) and then just divide one value by the other.
>>
>>Similarly, you would store different length units in terms of meters, different area units in terms of square meters, etc.
>
>Hi Hilmar,
>
>but then you got two operations between non SI with two imprecise operators.
>This limits the array to n-1.
>If you do full you get n² and with division minimum sum(x-1) for x=1,n but for the cost of more code. Depends a bit on the
>-time to create the array vs time to run complex code
>-speed you need
>-complexity
>
>In sense of speed a full blown CASE struct is very fast (two to three (if you parse out same target extra) decisions) but very complex.
>Two decision thing code grows faster then square, n²+n I guess. Sounds not very comfortable.
>
embolded part is true in theory at least, but in reality hinges on implementation detail or language spec for switch: a pascal case on integer types can be compiled into a direct jmp, whereas in many switch constructs this depends on the break rules: a fall through like the vfp case will be slower, esp. with strings. switch with automatic break can be compiled into a hash of jmp vectors, but a hash access of the factor could be fast as well