Re: [boost] Interest in dimension/unit-checking library?

From: Phil Richards (news_at_[hidden])
Date: 2005-10-20 10:51:37

On 2005-10-12, Matt Calabrese <rivorus_at_[hidden]> wrote:
>  On 10/11/05, Deane Yang <deane_yang_at_[hidden]> wrote:
> > But couldn't this be done rather nicely using the MPL map type, using a
> > compile-time rational number type? I'm not exactly sure how to contruct
> > the derived unit type from the unit types of two factors, but I bet it
> > could be done most easily using this approach.
>  Yeah, in fact that's how I already work with types. The classifications and
>  unit types internally have maps whose keys are the fundamental types which
>  make up the derived type, and the mapped type is a group of information
>  which also contains the power of each fundamental type. All have to do is
>  use rationals, which I already have available, instead of integral types
>  inside the mapped type.

What are the "fundamental types" that are being referred to here?  I'm
guessing that it is the basis set for the dimensional analysis, and
hence would be something like: length, time, mass, temperature,
intensity, current, amount.

Is this a fixed set, or can it be overridden (not just extended)?  (This
is what, if memory serves, was one of the major points of discussion
back in 2003/2004.)

What I mean be overridden is: Could I choose to use velocity, force, and
pressure as the basis for my dimensional analysis (so rather than
thinking of velocity as "length / time", length would be represented as
"pressure^-1 force^1 velocity^-2")

Personally, I think this level of flexibility is pointless and
overcomplicates things, but I feel I have to ask given some of the
discussions last time around... :-)

If it can be expanded, can it be extended arbitrarily by any code
anywhere, or is it possible to define a "family" of dimensions
for specific use?  In other words, if one part of my system is
fiddling around with "traditional" dimensional analysis (the 7
ones listed above), and another part is interested in "bedknobs"
and "broomsticks" dimensional analysis, could I do
        bedknobs(1) * mass(1)
(or some such)?  Or can I constrain what various parts of the
code are doing so that that expression would be invalid because
"physical quantities" do not have a "bedknobs" dimension?

I went for the latter approach: This resulted in doing things like:

struct SI :
    physical7_system<u::kilogram, u::meter, u::second,
                     u::ampere, u::kelvin, u::candela,
                     u::mole> {};

struct Imperial :
    physical7_system<u::pound, u::foot, u::second,
                     u::ampere, u::fahrenheit, u::candela,
                     u::mole> {};

When a quantity was defined, you could do:
    SI::length<double> meter(1.0)
and you would get something that was in meters units, and stored as 1.0.
(This is equivalent to something like:
    quantity<double, ...dimensionality in physical_system7..., SI>
        meter(1.0);
Of course, there can be a raft of convenience typedef's to make things
more usable/readable.
)
and then:
    Imperial::length<double> foot(1.0)
and you would get something that was in feet units, and stored as 1.0.

You could then do:
    SI::length<double> footInMeters = convert_units<SI>(foot);
which would store a value of 0.3048 in footInMeters (since the internal
representation is in units of meters).  Personally, I'm with Deane Yang:
I don't like implicit conversions.

If you then introduced:
struct Silly :
    disney_system<u::bedknobs, u::broomsticks> {};
And did
    Silly::sleeping<double> s(1.0);
this would *not* interact with, or convert to, anything in the
physical7_system of dimensions.  I've never actually needed this
level of functionality, so I've never be inclined to wonder
whether it was overly restrictive or not :-)

Oh, and it did fractional powers and printing, too.
And supported absolute (sorry, point) quantities.
(Thanks to an approach suggested by Jan Langer, if I remember
correctly.)

I gave up trying to progress with boost-ing it because I couldn't see
a path of consensus to what was actually wanted.  There seemed to be
a desire for more flexibility, and I couldn't see the point :-(  (One
of the few things I took from a brief flirtation with eXtreme Programming
was YAGNI and "do the least amount that will work".)

In fact, all I've ever needed is physical4_system (mass, length,
time, temperature), and never need to convert units because we
always insist on everything being in SI.

phil
-- 
change name before "@" to "phil" for email