RE: [boost] Quantity libraries: SIunits

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-09-11 13:13:58

I support WEB's view that currency is too different (not unimportant!)
and that SI units are enough to work on for now.  Lets not bite off
more than we (WEB) can chew!

Paul

(Calender Time is also too complicated to involve fully in SI units).
SI unit of time is seconds and that's enough for this library.

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
Mobile [phone]
mailto:pbristow_at_[hidden]

> -----Original Message-----
> From: wb_at_[hidden] [mailto:wb_at_[hidden]]
> Sent: Monday, September 10, 2001 10:04 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Quantity libraries: SIunits>
>
> 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
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/