[boost] Re: runtime unit-modifiable physical-quantitiesusingpqs1-00-01

From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-03 17:08:18

Andy Little wrote:
>>I did provide in a much earlier posting a precise abstract mathematical
>>definition of what is needed, but I guess it was a little hard to
>>follow. (1-dimensional vector spaces, their duals and tensor products)
>>

> Point me in the direction and I'll happily pass judgement. :-)
> 

Pure mathematical description:
http://tinyurl.com/32x47

More practical description:
http://tinyurl.com/2ynrr

>>And I have yet to see anyone give a precise definition of what a
>>"physical dimension" is.
> 
> 
> Is this on boost or just in general?
> 

I was only talking about on boost, but I actually have
never understood any explanation ever given to me.
Could you or someone else please try? By private e-mail
if it's off-topic? Or is there a web page I can stare at?

In any case, physical dimensions are completely consistent
with the purely mathematical description referred to above.
BUT the purely mathematical description is universally useful
anytime one has a linear measure of quantity of any kinds
(oranges, coupon periods, bytes, etc.). Physical dimensions
provide just one particular set of examples.

Since, as far as I can tell (which admittedly is not that far), 
virtually every use of a "double" corresponds to a measurement
of some quantity, I've sometimes been tempted to assert that one
should never write code with bare doubles and that every one should
be replaced by the appropriate unit class. This, in fact, is what I now
do in my own code. The compiler now catches coding errors, where I've
either used inconsistent units or written an arithmetic formula that 
makes no logical sense.

> I hope to look into calender time and conversion to (maybe even from :-) )
> physical_quantities time
> at some stage... maybe will look at Date class conversions. (BTW doesnt Date
> use implicit conversions ? :

But but but....I think the point I am trying to make (unsuccessfully) is
that a properly designed units library should not actually define any 
units itself. The units should be created only by the user of the 
library. Then there should be libraries derived from the units library,
like the physical dimensions library.

I see nothing wrong with focusing on a particular use case when 
designing the library, but if you want a truly useful C++ library,
you want to design its guts so that they can be used by the library
user to define whatever units the user happens to need. I think it
is an error for the library writer to try to predict what units
the library user needs.

> 
> I dont know what a coupon period is.. if its a time can do it, can do years
> squared, cant do root of years though.
> 

I am surprised. Fractional powers are useful even for physicists.
In fact, it arises in finance because finance uses Brownian motion,
which of course is originally a physical concept.

A coupon period is an unspecified amount of time; how long it really
is will be specified by the library user. The point is that the library
writer is not and should not be able to anticipate exactly what units
the user needs.

>>I would also say that on the basis of what I've read here, Matthias's
>>approach looks closest to what I'm looking for.
> 
> 
> Yep  Matthias...
> 
> 1) Is using MPL
> 2) uses SI units syntax
> 3) Is doing kumquats
> 

When I cite Matthias's library, I mean its core, where no physical units
are defined at all. I can't speak to the physical dimensions part.

I have only admired MPL from afar and have never used it, but it would
appear to be ideally suited for an abstract units library, as both
David Abrahams and Hugo Duncan demonstrated a while back.