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;
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk