Date: 2001-08-31 15:51:22
The quantity library that is being discussed here is a much
more ambitious effort that does not do what I need. I would
like to see a smaller, simpler library broken out of it that I think
would be much more useful to more people. After all, how many
people really need to work with all these different physical units?
I'm willing to bet that even in most physics-oriented software only
a limited number of units are really needed.
I want a small library that does not associate units with specific
physical or geometric concepts (like distance, mass, time).
In particular, I do not want the library to assume that different
units measuring the same "quantity" are necessarily convertible
into each other. I do want explicit casts required to convert one
unit into another.
So I really do not want a library that internally stores a given
quantity into a fixed predetermined unit, determined at runtime or
compilation. Although this approach might make sense in some
situations, I don't think it does in others (see below for an
My main example are the calendar units of time: days, weeks,
months, years. These are all "units" of time, but only a few
conversions should be allowed. Conversion between days and
years should simply be forbidden. Not that you never do it, but if
you do, you better do it explicitly yourself and clearly document
how you are doing it (is it 360, 365 or 365.25 days per year?).
But conversions of days to weeks or months to years should be
allowed (still, I prefer an explicit cast).
And, as for the question of mixing units of different orders of
magnitude in one application, how about a program that uses
calendar units for time, but also wants to measure, say,
execution time in milliseconds?
I also want to be able to control the number type used to
represent the quantity. I use both "Days", which are represented
by integers, and 'DayFractions", which are doubles, in my code.
The other thing is that even if there is an obvious conversion, I
don't necessarily want the quantity library to do it implicitly,
because there is a good chance that it is a sign of a design
or implementation error. A library that allows implicit conversion
should be built as a wrapper around a library that does not.
The library I have in mind is much, much smaller than the
quantity library and therefore maybe not worth the time and
attention. Some day I hope to find the time to present my feeble
efforts in this direction in more detail. All I can say is that in
what little programming I have done (financial valuation
software), these classes have allowed me to catch virtually all of
my coding and even some design errors through a mindless
process of fixing compilation errors and a very small amount of
The other thing is that I think the library I have in mind is
connected with operators.hpp, but I haven't studied what has
been going on with operators.hpp. There is a myth that
mathematical objects have no units associated with them.
The difference between an abstract n-dimensional vector space
and R^n is that the latter is the former along with a choice of
units. I believe that a properly implemented "units library' would
be useful, even in mathematical libraries like the linear algebra
library being discussed here, too. There is no conceptual
difference between changing between different units and
changing between different bases on a vector space.
If you actually read this far and think this is worth thinking about
(in addition to the quantity library being discussed), please let
me know. Otherwise, I'll just shut up. I am in complete awe of the
level of discussion in this group and am more than happy to
return to lurking status.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk