[boost] Re: Re: Re: Dimensional Analysis

From: Andy Little (andy_at_[hidden])
Date: 2005-01-30 05:33:16

"Phil Richards" <news_at_[hidden]> wrote in message
news:20050129141037.DE6D0E305_at_derisoft.derived-software.demon.co.uk...
> On 2005-01-28, Robert Ramey <ramey_at_[hidden]> wrote:
>>  The fact that units is required and important shouldn't inhibit the
>> utility
>>  of a dimensional analysis library.  Ideally, a units library would
>> depend on
>>  a dimensional analysis library. But a dimensional analysis library
>> should be
>>  able to stand on its own.
>
> Indeed it does.  I use one every day... we don't care about unit
> conversions because we don't do any.

I would hope that a general purpose physical quantities lib would deal with
units, even if you dont use anything but the base units. The Mars lander
crash and all that. IOW you need to be explicit about what units you are
using.

> We also don't care about anything
> but 4 of the dimensions, so that's all we use.
 (We could use more - it
> is just an mpl::vector of fractional powers.)

With pqs I was trying to create a concrete type. IOW I was very preoccupied
with making a simple user-interface. I go back to the example of
std::string. (which is an interface). Whatever its faults I dont want in
general to create my own allocators or char types every time  use it.  So
though I accept  the idea of customising the number of *base-units* [1] ,
for a widely useable set of  physical quantities types a default the 7 in
the S.I. system are required. The *unused*  base-units increase compile
times and lengthen the signature for error messages, but because of its
universality this is worth  it.

I opted not to use a mpl::vector, rather each base-unit is given its own
type, which is more understandable in error messages.  Again this is due to
a concern with the user-interface.

> Still, as I said, agreement couldn't be achieved last time round on
> pretty much anything,

This seems to be a pessimistic view of what went on IMO. Is it not up to the
librray designed to come up with a solution based on the  discussions. I
incorporated some things from these discussions into pqs.  However I have
always had a very specific view of what I want from a physical_quantities
library, which has naturally had a major influence on the design.  Some
things that came up were

* Fractional dimensional-exponents.
* What is the result type from a calculation of dimennsionally-equivalent
types but of different units.
* How do you distinguish dimensionally equivalent but different quantities.
* Angles

(One not dealt with yet is centigrade)

Another frequent point was "money as a physical quantity". Money is not a
physical quantity, Nevertheless there is a place for another type, built on
the building blocks of currency and physical quantities:

area::m2 wall_area(length * height);
apply<divides,currency::dollars,area::m2>::type cost_per_sq_m ; // <-- here
in >> cost_per_sq_m;
currency::dollars cost =cost_per_sq_m * wall_area;

However this presupposes the currency and physical quantities libraries

For all these things A universal operator type deduction mechanism is
required, while waiting for decltype. BOOST_DECLTYPE may provide the
interface but there needs to be an underlying framework too. May still be
reqd after decltype too.

> and life is too short to discuss whether angle
> should, or shouldn't, be able to be treated as a dimension that
> sometimes is, or isn't, dimensionless...

Though if there was to be a boost version, unfortunately this would need to
be thrashed out. And that is the problem. It is a big project. I would
ideally like to 'boostify' pqs but dont have time currently.

However Robert Rameys idea to do the dimensional anlysis library alone seems
good, as it is less contentious and surely would not be too much work Still 
requires
generic operator result_type deduction though, whether based on mpl,
result_of, BOOST_DECLTYPE, lambda lib,spirit or whatever...

[1]
( FWIW The term dimensions is incorrectly used here.  According to S.I. the
correct terminology is dimension
of  the systems base units)