Re: [boost] SIunits and quantity library concerns

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-10-04 12:52:06

> |                                                                 From
> | the discussion on the news group I now admit that user defined units
> | are probably a very bad idea.
> 
> (3)  I'm less certain about this, because I believe that most, if not
> all, units corresponding to measurable quantities arise because someone
> (a "user") defined them as such.

I think that most users, most of the time, will probably be satisfied 
with a fully-featured set of predefined units. But not having the hooks 
to allow a user to add a unit would be, IMHO, a serious omission. 
Adding a quantity is a different matter.

> |                                But, user defined quantities like
> | "apples", "oranges", "fruits", etc are important from the programming
> | perspective.
> 
> (5)  This is precisely what I'd like to understand better, and not only
> from "the programming perspective"!  I think that "apples" qualifies
> neither as a quantity nor as a unit, but I'm willing to be convinced to
> the contrary.  For the moment, let me apply the term "qualifier" to
> "apples" and such while I struggle to identify some of my concerns.
> 
> (6)  Suppose these qualifiers function as units.  Then it would make
> sense to ask what quantities they measure.  I will therefore ask, "What
> quantity can I measure in units of apples?"
>
> (7)  Suppose, instead, these qualifiers function as quantities.  Then
> they represent a measurable attribute and so it would make sense to ask
> in what units they can be measured.  I will therefore ask, "In what
> units can I measure the apple of something?"

I think you're missing a couple key words which are obscuring things 
here. The quantity is apples, the unit is number of apples. Or you 
might use units of bushels, or crates, or truckloads of apples instead.

So I can measure the 'apples' of a shipment to a particular grocery 
store in any of those units. Apples aren't as general quantity as 
length or weight, which is why your phraseology in (7) seems odd to our 
ears, but I think my answer is right. All of these would be based on 
the Amount quantities in SI, I think, because they are counting things. 
(Digression: this is where the chemists probably would want some help 
too. They don't want to add 2 moles of oxygen to 1 mole of carbon and 
get 3 moles of carbon dioxide, by mistake.)

Then, you could multiply a quantity by an empirical value in units of 
kg/apple (or bushel_of_apples) and get kg. Or, say you wanted to be 
more careful: say you were loading trucks, and each truck had a maximum 
weight. You could multiply, get mass_of_apples, mass_of_bananas, 
mass_of_olive_oil (which probably came from a differently structured 
underlying quantity, but I digress), and add all three of those to get 
a Mass-quantity result, expressed in kg or in Imperial tons (because 
the shipment is going to the US, after all...). These quantities have 
something in common; they all ARE-A mass. But they also have a more 
precise derived type. One could probably make quite a bit of progress 
by just adding a qualifier tag to the basic SI framework, and then 
Mass<apples> would derive from Mass<void>. I think there are probably 
quantities that aren't physical that people still might want to used. 
Perhaps Amount<> could still be used for currency with these tags, but 
it doesn't quite seem right. I could be convinced otherwise on this.

I'm not quite sure where to fit into the puzzle the other remaining 
issue that bothers me. Walter, maybe you could clarify something for me 
in SIUnits, which I couldn't find in the documentation. Suppose I like 
measuring things in degrees. Can I write in the current framework:

Scalar<> angle = 30 * degree;

and then:

cout << units::degrees << sin( 3 * angle );

and get 1?

I think an angle is a nice example in the mathematical domain of a 
quantity of something which is logically distinct (I'd rather not find 
myself adding something which is not an angle to an angle, most of the 
time) but physically dimensionless, so I think exactly how angles are 
treated will also serve as a useful example to guide our thinking.

I think Kevin Lynch has made a nice statement about the 
non-bijectiveness of these conversions, and also why Currency hasn't 
appeared. I'd like to add that the reason I haven't done it is that I 
think it's vitally important that a currency library not stand on its 
own; it has to interface with SIunits, or whatever it might turn into. 
The current discussion is crucial input as to the form such an 
interface will take, and what of SIUnits might need to get changed or 
extended in the process.

George Heintzelman
georgeh_at_[hidden]