[boost] Re: Re: Re: Re: Physical Quantity- boostified

From: Andy Little (andy_at_[hidden])
Date: 2003-11-18 06:28:59

"Daryle Walker" <darylew_at_[hidden]> wrote in message
news:BBDF5456.2B60%darylew_at_hotmail.com...
> On 11/16/03 3:19 PM, "Andy Little" <andy_at_[hidden]> wrote:
>
> [SNIP]

[snip]

> I know how dimension/unit types work.

Apologies. Yep... I have been ticked off for "rambling" up in the thread
.... :-)

>
> If your actual work is structured like what you have in your example, then
> you have a bunch of nested types within a class template, right?  I guess
> the outer template is for the scalar type
> (can't tell since you use
> defaults),

Ok noted ..Sorry I didnt think.
One of the nasty aspects of using defaults I guess ... legibility and
comprehensibility go squish.

> and the inner type is the actual unit.  I think other libraries
> of this type have the scalar type and units at an equal level.
>
> I'm not sure that the system you have here is extensible.  You also have
> strange combinations of units (mm/s, m/minute).  This implementation
forces
> you to provide every potential combination in the class,

The user can define which combinations se wants.
The pq type does the rest.
Here  is a part of ( an include in ,comprising) the user level header:

namespace physical_quantities{

    template< typename value_type = pq_default_value_type>
    struct pq_force{                                    //^ ie float
,double,int etc

        typedef physical_quantity<
                value_type,
                1,-2,1,
                of_length::m,            //of_length::mm is a named enum
                of_time::s,                // etc...
                of_mass::kg,
                of_quantity::null>
            N;

        typedef physical_quantity<
                value_type,
                1,-2,1,
                of_length::m,
                of_time::s,
                of_mass::kg,
                of_quantity::kgf>
            kilograms_force;
    };
}//namespace physical_quantities

To create a new unit you add a typedef  (outer struct etc omitted)
as above using the dimension/pq units units you require:
...
typedef physical_quantity<
                 value_type,
                1,-1,0,
                   of_length::mm,
                of_time::minutes,
                of_mass::null,
                of_quantity::null>
            mm_per_minute;

        typedef physical_quantity<
                value_type,
                1,-1,0,
                of_length::miles,
                of_time::hours,
                of_mass::null,
                of_quantity::null>
            miles_per_hour;
....

That is all there is to it from the users point of view.
The user can also define units at dimension/ pq level , nearly as simply,
requires to add a specialisation of a function and an enum.

note: I plan to implement the full 7 dimensions when I have the basics well
sorted.
The powers of dimension will probably be made into a class
ie  typedef Pclass<1,-1,0,0,0,0,0> velocity ;  etc
possibly a mpl::list_c<...> or mpl::vector_c<...>
The 'of_xxx' enums provide typesafety to catch typos, and seem more legible
as they are,
but could be made a class also I guess.

>
> You provide "easy" conversion between different units of the same
dimension,
> but what about different scalar types (of the same units and/or
dimension)?
> How do you provide the unit conversions?  You can't use template
parameters
> if a conversion isn't a pure integer (I think meters <-> miles is like
> this).

The various units use "integer log placeholders"( actually impled in my ver
as the enums identifying the unit)
 to stand in for the f.p. constants
at compile time.  see here:

http://lists.boost.org/MailArchives/boost/msg55359.php

The f.p. scalings all resolve to a constant *times* the wrapped m_value of
the pq.
The constant part is resolved by using a static variable in a function,
hence only computed
first entry. This is implemented in 'VC7.1 unoptimised' as a bit flipped
first time thro to note calc is done.

There will be some"inertia" at start up, but in my terms of requirement
utility is more important than the last bit of speed.

regards
Andy Little