Re: [boost] Quantity libraries: SIunits

From: wb_at_[hidden]
Date: 2001-09-10 16:03:38

George A. Heintzelman <georgeh_at_[hidden]> wrote on Mon Sep 10 11:28:56 2001:

| > I believe that this is definitely the system to go for.  It meets all
| > reasonable needs, except ... [MSVC]
|
| I disagree with this characterization of SIunits. First, let me say 
| that I'm impressed with SIunits as it stands. It is a great package, 
| and I think it's definitely an excellent base to work from.

Thank you.

| But, SIunits was designed by a scientist for dealing with unit problems 
| in scientific programs, and it shows.

Yes, I am a (computer) scientist, but SIunits was not designed for
exclusive use by the scientific community.  SIunits was designed, as
its name was intended to suggest, to cover those areas of unit-based
computation in which international consensus has already been achieved
as promulgated by the International System of Units (SI).  SI is an
international treaty and, as such, I am given to understand that it has
the force of law.  (I'm not a lawyer, but the language at www.bipm.org
certainly gives this impression.)

|                                       For example, in the business 
| domain where I currently hang my hat, I don't see how the SIunits 
| package helps people who need to deal with currencies, or 
| weights/measures of particular materials/classes of objects (commodity 
| prices, for example -- I would love to have a package which prevented 
| me from multiplying the price for a contract for pork bellies with a 
| number of bushels of wheat to get a dollar result).

In one of its many incarnations, SIunits had an extensible component in
order to allow its users to configure additional "dimensions" such as
currency.  However, I heard from a number of prospective users that
this was a mistake, in part because this introduced a certain amount of
incompatibility from program to program and made their library
development efforts problematical.  I found this argument persuasive,
and removed the feature.

However, I am willing to reconsider this decision.  The issue of
currency, in particular, has come up again and again.  However, it is
far from clear to me how to handle currency conversions, for example.
Unlike physical quantities, in which constants of nature play a major
role, currency operates under rules that change regularly.  There are
also specialized rules for arithmetic, I understand.

I thus believe that currency is a sufficiently specialized domain, with
its own rules, as to warrant the design of its own library.  If it can
be integrated with SIunits at some point, I am more than willing to
consider doing so.  As one correspondent pointed out to me, it is
certainly meaningful to talk about a "price per volume" quantity that
can be measured, for example, in dollars/barrel or euros/litre.

While I'm at it, another oft-heard request is for additional tagging of
quantities, as in "a teaspoon of sugar," in order to affect such a
quantity's commensuration with, say, "a teaspoon of salt."  This, too,
is beyond SIunits at this point and strikes me as yet another
specialized domain, bordering on what in chemistry is known as
stoichiometry.  For example, 1 mole of sodium + 1 mole of chlorine will
produce (under the right conditions, of course) 1 mole of salt, not 2
moles of sodium/chlorine stuff.  (I hope my chemistry is right -- it's
been a long time.)

|                                                     Even within the 
| scientific domain, I don't see how to make SIunits detect errors in 
| degrees/radians/arcseconds measure (well, maybe I do, but I think it 
| has other undesireable consequences for other dimensionless quantities).

What errors are these?  Measurements in degrees, radians, and
arcseconds are, by definition, commensurate and can be freely and
meaningfully summed (with appropriate conversions, of course).  I agree
that dimensionless quantities need careful treatment, in general, but
so do all quantities, in general.  Unit errors, in my experience, are
far more prevalent than is commonly realized; see my paper for a small
case study in which SIunits exposed 3 errors in a mere 6-statement
function.

I do not claim SIunits will solve all quantity-related issues, but I do
believe it is a reasonable step toward addressing fundamental issues of
commensuration as defined by the International System of Units.

| I think one can reasonably expect a units package to meet those needs, 
| and I think the problems are soluble. I hope that SIunits' author will 
| be willing to work with boost to address these sorts of problems as we 
| move from a specifically SIUnits package to a more general 
| quantity/units library.

Even if this is a reasonable expectation, I suspect that the production
of a "more general quantity/units library" is far, far harder than
appears to be the case at first glance.  I would be delighted for
others to share their views on this, especially to help identify the
relevant concepts above and beyond the basics of commensuration.  We
need examples, proposed rules, and other resources for detailed study
and discussion of the issues.

At the moment, SIunits has a well-defined international standard
underlying it, and I believe SIunits to be useful in its present form.
Extensions are always a possibility, but only after careful thought to
weed out misconceptions and provide genuine utility in a general form.

Yes, I'm certainly "willing to work with boost."  Thank you for sharing
your views re SIunits' functionality.

        - WEB