Re: [boost] Boost Units library preview

From: Andy Little (andy_at_[hidden])
Date: 2006-08-27 04:52:36

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
news:ecr5ti$bls$1_at_sea.gmane.org...
> Andy Little wrote:
>> "Deane Yang" <deane_yang_at_[hidden]> wrote in message
>> news:ecpndi$2mb$1_at_sea.gmane.org...

>>  Dealing with the ValueTypes first, the result type of ValueType1 *
>> ValueType2
>> is encoded in the compile time expression:
>> binary_operation<ValueType1,times, ValueType2>::type.
>> The implementation provides a specialisation for inbuilt types, and this
>> follows
>> the promotion/conversion  rules on the respective calc in the C++ standard.
>> We have also been recently testing with boost::numeric::interval and (with
>> the
>> appropriate specialisations) this seems to be working now and I believe that
>> other numeric UDT ValueTypes will now work OK.
>
>
> Does this mean that if ValueType1, ValueType2, and ValueType3 are UDT's
> and I do something like:
>
> template <>
> struct binary_operation<ValueType1,ValueType2>
> {
>   typedef ValueType3 type;
> };
>
> then everything will work properly?

Yes. though there are versions  of binary_operation for +,-, *,/ and pow . and
there are a couple of other requirements. One is (only if you use non SI units)
that the UDT can be multiplied by an inbuilt type.
The other is that you need to tell Quan that your UDT is intended to be a
numeric type by specialising quan::meta::is_numeric for it, to return true.
Also each UDT seems to have its own peculiarities. For example
boost::numeric::interval can only be raised to an integer power, AFAICS, so
it is quite difficult to come up with a generic quan::pow<N,D>(udt, ??) function
and I think it will be necessry to create an overload in the quan namespace per
udt, which checks any requirements and forwards to the relevant udt's function.
Here is the quan::pow function that seems to work OK for
boost::numeric::interval:

template <int32 N,int32 D,typename T>
    inline
    typename quan::meta::binary_operation<
        boost::numeric::interval<T>,quan::meta::pow,quan::meta::rational<N,D>
    >::type
    pow ( boost::numeric::interval<T> const & v)
    {
        BOOST_STATIC_ASSERT(D == 1);
        typedef typename quan::meta::binary_operation<
            boost::numeric::interval<T>,quan::meta::pow,quan::meta::rational<N,D>
        >::type result_type;
        result_type result
        = boost::numeric::pow(v,N);
    }

Bear in  mind that I am talking about the latest CVS version on two_param Branch
ins the Quan Sourceforge CVS, where I spent some time on getting UDT's working
last week.

Anyway I am fairly sure that in general UDT's can be made to work with Quan, but
not totally effortlessly unfortunately.

>>
>> The dimension of the result is found by adding the respective dimensions of
>> the
>> operands. ...
> > <snip>
>
> Oops. I guess fixed_quantity has to have one of the physical dimensions
> represented in SI units, eh? Never mind.

No. Firstly the Concept of unit is separate from the Concept of dimension.  A
quantity within a particular unit system can have various units but be
dimensionally equivalent.

Secondly, fundamentally the dimension of the quantity is represented as a series
of numbers, ideally rationals but in limited cases you can get integers to work
(just no division). Those numbers can be taken to mean anything in any unit
system you want. The StaticUnit doesnt expose the dimension directly so you can
have dimension represented any way you want, with any number of elements. You
can see an example using a mpl::vector here:

http://tinyurl.com/kbvbq

The implementation of the quan::Static Unit concept for the above is here, note
again the use of binary_operation, which is overloaded for many purposes

http://tinyurl.com/k3ofd

There is also a refinement of Static Unit namely Static SI Unit. It is only at
the Static SI unit level that the dimension is assumed to be made up of the 7
base SI quantities. The particular unit system for a Static Unit can be queried
by get_unit_system<StaticUnit>::type. If the unit system is the SI unit system
then the implementation assumes that the Static Unit is in fact a Static SI Unit
too, a bit like dynamic_cast for a down cast maybe.

OTOH it should be realised that I have only provided a fleshed out
implementation for the SI unit system and that checking for other unit systems
is quite new and not yet fully realised, however the potential is there, though
it probably needs an implemenattion or two to see whether it will work in
practise.

regards
Andy Little