|
Boost : |
From: wb_at_[hidden]
Date: 2001-10-04 10:49:42
Thanks for this input; it raises several important issues, I believe.
Because I'd like some clarification on these, I've inserted some
comments and questions below in order to help me get a better handle on
the underlying concepts. (My paragraph numbers are only for reference
purposes.)
Dean Foster <foster_at_[hidden]> wrote on Wed Oct 3 21:12:20 2001:
<snip>
| Using the correct language, I now realize that I basically wrote and
| used a quantities library rather than a units library.
(1) In my opinion, a library along the lines we are discussing must
provide both. If we are to have measurable quantities available, we
almost certainly need corresponding units. While, for example, I've
chosen the name SIunits, my library incorporates quantities as well as
units. I suspect you've done the same.
| From that
| project, I learned that user defined quantities are important.
(2) I agree with this statement, but I suspect we don't yet quite
agree on what a "user defined quantity" is. See below.
| 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.
(4) Standardized units emerge by consensus, of course (that's why
they're "standard"), but someone (a "user") had to have made a
proposal. I see no inherent reason to forbid future users from making
up new units that they find convenient; if enough others agree on their
utility, the new units may even find their way into a future standard.
I'm sure that this is how the katal (a unit measuring catalytic
activity) ended up in the latest revision of SI.
| 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?"
(8) At the moment, I can't satisfactorily answer these questions, and
hence I tentatively conclude that the concept of qualifiers is
orthogonal to the concepts of quantities and units. Can someone argue
otherwise?
| Further when such quantities are multiplied, the
| underlieing dimensions should not be lost. (i.e. if the fruits are
| measured in Kgs, multiplying apples times time can't simply yield kg*s
| it must be (kgs of apples)*(seconds).) This one idea is the only
| thing that I feel I've learned from creating and using a quantities
| library.
<snip>
(9) I'm not yet ready to consider multiplication involving qualifiers,
sorry. The only operation I'm ready to discuss is "aggregation" (or
"accumulation"?), which resembles addition, of course. However, it
differs from addition in an important way: meaningful addition
requires that its operands be commensurate; aggregation has no such
requirement (hence, "apples + oranges"). Aggregation seems to require
inventory-like concepts; any ideas, anyone?
- WEB
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk