SIunits and quantity library concerns

From: wb_at_[hidden]
Date: 2001-10-03 13:56:12

I've stayed out of this discussion for a few weeks now to see whether a
consensus would form, but it seems not yet.

Part of the reason, it seems to me, may be that there are some serious
abuses of nomenclature in many of the postings.  Another reason, I
speculate, is that no one has yet put forth a set of concepts that
would cover the desiderata over and above what SIunits provides.

I am writing today, therefore, in order to address a number of recent
concerns, questions, and proposals re the general issues surrounding a
quantity/units library, and re SIunits in particular.  I apologize in
advance for the length of this posting, but there's been quite a fair
amount of discussion since I last took active part.

Let me first repeat some of what I have said in previous postings:
The International System of Units (SI) very carefully distinguishes
        a (measurable) quantity
from
        the units in which such a quantity can be measured.

I understand that there may be confusion about this, because the term
"quantity" is, in computing as in other domains, often used to mean
other things.  For our purposes in this thread, however, I believe it
is important to stay exclusively with SI's nomenclature in order to
avoid confusion.  For the sake of consistency, I ask all discussion
participants to stick to this terminology.  (We could, I know, speak
of "quantity in the general sense" versus "quantity in the specific
sense" instead, but I believe that that's just too cumbersome.)

The next step is to decide how the concepts of quantity and unit fit
into a programming context, specifically (for Boost) in the context of
C++.  I respectfully contend that a quantity very naturally fills the
role of a type, while a unit fills the role of an object (typically
const).  Thus, using SIunits' notation, we can write, for example:
        Length<> len = 16 * meter;
        Area<>   a   = len * len;
and so on.  SIunits does not commingle the two concepts in any other
way.

I understand, from some previous postings, that some prospective users
would prefer a different approach that uses both quantity- as well as
unit-tags, e.g., something like:
        Amount<LengthTag,MeterTag   >  len = 16;
It's not clear to me, however, which of the following would ensue:
        Amount<AreaTag  ,MeterTag   >  a = len * len;  // ?
or:
        Amount<AreaTag  ,SqMeterTag >  a = len * len;  // ?

While I understand that at least some of this was motivated by a desire
to avoid implicit unit conversions, I believe this approach has some
inherent difficulties.  How, for example, would the code determine the
correct unit tag for:
        Amount<LengthTag  ,MeterTag          >  len = 16;
        Amount<TimeTag    ,SecondTag         >  s   =  5;
        Amount<VelocityTag,MeterPerSecondTag >  v   = len / s;  // ?
I'd like to understand this better, so I can properly evaluate it.

FWIW, my colleagues and I do want implicit unit conversions, but only
pursuant to an underlying choice of view.  As outlined in my paper, a
view determines (among other choices) the user's desired calibration,
i.e., what is meant by a 1 in each base quantity.  For example, a
Length<> of 1 could mean a meter, a centimeter, a light-second, etc. --
but the choice of view makes it clear.  The view concept is central to
SIunits!

On a related subject, it is also not at all clear to me what the
correct concepts are in regard to such problems as "1 apple plus 2
pears gives 3 pieces of fruit."  Suppose I subtract "3 pieces of fruit,
take away 1 apple"?  Do I get "2 pieces of fruit" or "2 apples"?
Both?  Neither?  What if I subtract "3 pieces of fruit, take away 2
apples"?  Do I get "1 piece of fruit"?  Or do I get "3 pieces of fruit
less 2 apples"?  Or what?  Can I meaningfully speak of "-1 apple"?
IOW, what are the rules underlying such aggregation?  Is this
inventory-like, or are there other abstractions?

There has also been a proposal suggesting the use of compile-time
hashing as an implementation technique.  While SIunits does not today
use this approach, there is no inherent reason that it could not --
provided that the hashing does not interfere with determination of
commensuration.  If there is any possibility of an incorrect
determination of commensuration, then I could not, in good conscience,
agree to it.

In response to some recent concerns about the need for rational powers
of quantities and corresponding units, I can only state that it has
been made clear to me by several colleagues that this is a requirement,
and at least some recent posters have concurred.  Indeed, as my paper
mentioned in a footnote, there are applications that would benefit from
fully real-valued powers, were this feasible!

In reply to yesterday's question about the functions provided by
SIunits, let me mention that SIunits provides all the functions
mandated by the C++ standard in its <cmath> header, plus a (very) few
more at the moment.  This includes all the power, root, exponential,
trigonometric, etc., functions.

It is important to note, however, that these functions fall into two
categories:  those (such as pow) that apply to all quantities, and
those (such as log) that only apply to scalar ("dimensionless")
quantities.  The distinction is based on the respective functions'
definitions.

Finally, I am disappointed that no one has stepped forward to help
address the oft-repeated request/need for a general-purpose Currency
library.

I welcome further discussion on any/all these issues.

        - WEB