Re: Re: Re: Re: quantity libraries

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-08-31 02:51:03

>   From: Anatoli Tubman <anatoli_at_[hidden]>
>
>I'm still asking: given that different users want different
>units, and it's possible to give everyone what they want without
>harming anyone, why insist on a SI-only library?

Well, now that the stampede to prove (or attempt to disprove) what we
already know to be true [1]. It may be worth pointing out that in the
flurried excitement of posters vying to be right, they forgot the
context of the original posting. For clarification, here it is:

>>A quantity library that wishes to support both metric
>>and English units must chose one of the following:
>>
>>1. All length are stored in meters.
>>2. All length are stored in feet.
>>3. All length are stored in units specified at configure time.
>>4. Some lengths are stored in feet, others in meters.
>>
>>Every choice has its problems. Choices 1 and 2 are giving unfair
>>preference to users of a particular unit system.
>
>I'm not sure what the problem is. Choosing between 1 and 2 is easy: 1,
>without a shadow of a doubt. The choice in this case is informed by the
>fact that the meter is the more fundamental concept: the foot is
>officially defined in terms of the meter, and can therefore be
>considered something of a derived unit :->

In other words, if the choice is only between 1 and 2, the case for 1 is
far stronger than for 2.

However, it seems fairly obvious to me that what needs to be discussed
in a general (rather than specific) quantities library is how to cater
for domains that prefer electronvolts to Joules and light years to
metres. Remember that we are talking about the underlying representation
here, which does not affect the code that the user writes: neither the
metre nor the foot defines a system of measurement; they are both
constants. A quantity library that requires the user to introduce an
explicit conversion between feet and metres needs fixing.

The case for 3 (configuration time) is quite strong as it implies a
configuration that leaves the meaning and form of user code unaffected.
It is certainly the most transparent. However, a potential disadvantage
comes with semantic interfacing compatibility: binary (or text) data
that has been stored wrt the underlying representation can be different
between different builds. OTOH, it would be fairly unwise to store such
data directly without appropriate (even if null) conversion. The issue
really comes with process binary compatibility: eg shared memory and DLL
versions.

The case for full support for 4 (generalised, as feet vs metres is not
that useful) is weakened a little by the potential for combinatorial
explosion. However, it is possible either to go translate through a
single system (eg SI) or to select some common conversions that require
only one step. For instance, eV to J is worth having a direct conversion
for, but gigafurlongs to light years is of less use.

My preference is for 3, but I would be interested to know if anyone is
working with an application that would benefit significantly from
supporting two different underlying representations in the same program
at the same time.

If you have not yet done so, I would recommend reading Walter Brown's
draft work on this:

        http://home.fnal.gov/~wb/units.html

He has covered many of the issues that seem to be resurfacing here. He
is also presenting a newer paper on the topic at the C++ Template
Workshop at OOPSLA, in Tampa, 14th October.

Kevlin

[1] Namely:

- Length is a base SI quantity and the metre is a base SI unit.

- The metre has been defined wrt the speed of light in a vacuum since
the early 1980s, 299792458 m/s (sadly, this number seems to have been
etched in memory since my teens -- why can't I remember birthdays? :-}).

- The foot has been defined wrt the metre by treaty since the 1950s.

- Many Americans believe that they use English (or British) units,
except that in a number of cases these are not the units commonly used
in England (and Britain). A bit like the apocryphal English muffin that
you can buy at McD's!
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________