"Strong typing vs. strong testing"

George Neuner gneuner2 at comcast.net
Wed Sep 29 20:18:27 CEST 2010

On Wed, 29 Sep 2010 12:40:58 +0200, pjb at informatimago.com (Pascal J.
Bourguignon) wrote:

>George Neuner <gneuner2 at comcast.net> writes:
>> On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson <kst-u at mib.org>
>> wrote:
>>>George Neuner <gneuner2 at comcast.net> writes:
>>>> On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
>>>> <albert at spenarnc.xs4all.nl> wrote:
>>>>>I would say the dimensional checking is underrated. It must be
>>>>>complemented with a hard and fast rule about only using standard
>>>>>(SI) units internally.
>>>>>Oil output internal : m^3/sec
>>>>>Oil output printed:  kbarrels/day
>>>> "barrel" is not an SI unit.
>>>He didn't say it was.  Internal calculations are done in SI units (in
>>>this case, m^3/sec); on output, the internal units can be converted to
>>>whatever is convenient.
>> That's true.  But it is a situation where the conversion to SI units
>> loses precision and therefore probably shouldn't be done.
>>>>                              And when speaking about oil there isn't
>>>> even a simple conversion.
>>>>   42 US gallons  ?  34.9723 imp gal  ?  158.9873 L
>>>> [In case those marks don't render, they are meant to be the
>>>> double-tilda sign meaning "approximately equal".]
>>>There are multiple different kinds of "barrels", but "barrels of oil"
>>>are (consistently, as far as I know) defined as 42 US liquid gallons.
>>>A US liquid gallon is, by definition, 231 cubic inches; an inch
>>>is, by definition, 0.0254 meter.  So a barrel of oil is *exactly*
>>>0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
>>>kbarrels/day.  (Please feel free to check my math.)  That's
>>>admittedly a lot of digits, but there's no need for approximations
>>>(unless they're imposed by the numeric representation you're using).
>> I don't care to check it ... the fact that the SI unit involves 12
>> decimal places whereas the imperial unit involves 3 tells me the
>> conversion probably shouldn't be done in a program that wants
>> accuracy.
>Because perhaps you're thinking that oil is sent over the oceans, and
>sold retails in barrils of 42 gallons?
>Actually, when I buy oil, it's from a pump that's graduated in liters!
>It comes from trucks with citerns containing 24 m³.
>And these trucks get it from reservoirs of 23,850 m³.
>"Tankers move approximately 2,000,000,000 metric tons" says the English
>Wikipedia page...
>Now perhaps it all depends on whether you buy your oil from Total or
>from Texaco, but in my opinion, you're forgetting something: the last
>drop.  You never get exactly 42 gallons of oil, there's always a little
>drop more or less, so what you get is perhaps 158.987 liter or
>41.9999221 US gallons, or even 158.98 liter = 41.9980729 US gallons,
>where you need more significant digits.

No.  I'm just reacting to the "significant figures" issue.   Real
world issues like US vs Eurozone and measurement error aside - and
without implying anyone here - many people seem to forget that
multiplying significant figures doesn't add them, and results to 12
decimal places are not necessarily any more accurate than results to 2
decimal places.

It makes sense to break macro barrel into micro units only when
necessary.  When a refinery purchases 500,000 barrels, it is charged a
barrel price, not some multiple of gallon or liter price and
regardless of drop over/under.  The refinery's process is continuous
and it needs a delivery if it has less than 20,000 barrels - so the
current reserve figure of 174,092 barrels is as accurate as is needed
(they need to order by tomorrow because delivery will take 10 days).
OTOH, because the refinery sells product to commercial vendors of
gasoline/petrol and heating oil in gallons or liters, it does makes
sense to track inventory and sales in (large multiples of) those

Similarly, converting everything to m³ simply because you can does not
make sense.  When talking about the natural gas reserve of the United
States, the figures are given in Km³ - a few thousand m³ either way is


More information about the Python-list mailing list