A slightly different take on the quantity library

From: Deane_Yang_at_[hidden]
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 
example).

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 
runtime debugging.

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.