Boost logo

Boost :

From: Phil Richards (news_at_[hidden])
Date: 2003-12-12 07:02:19


On 2003-12-11, Matthias Schabel <boost_at_[hidden]> wrote:
> > Beautiful code. Poetry. I did get lost, somewhere along the way.
> > Lack of familiarity with MPL on my part, I guess.
>
> Thanks for the flattery - it was fun learning how to use MPL (after
> getting over my annoyance at the lack of documentation - talk about the
> pot calling the kettle black, though...). I don't think I would have
> had the fortitude to stick with it if MPL didn't exist. I'm eagerly
> awaiting the arrival of the mpl::set since I have a number of
> algorithms which are almost certainly suboptimal in efficiency.

I have to say that the lack of documentation was the thing that
stopped me from using the MPL in the physical quantities library
I started writing as a progression of what we use on a (real) project.

(I started from Dave Abrahams slides, realised that the
transform function he used didn't exist, tried to work out how
to do it with what was already there and gave up :-)

The one worry I still have with the MPL approach when combined
with the dimension-tagging approach you've taken is the compile-time
performance - in its current form it is, frankly, unusable.

As a comparison, the test_units.cpp program in YANL takes about
70 seconds to compile on my machine with gcc 3.3.2; using the
one I've written takes about 4 seconds to compile a straight
transformation of your test - the big difference (apart from not
using the MPL) is that I use a fixed list of dimensions in
the same way that DA's slides did - except, of course, they
are rational powers.

I look forward to the set-based MPL version making a significant
difference in compile-time performance!

If I can knock some documentation together, I'll stick a copy of
my code up on yahoo groups. I've been loath to introduce yet-another
library on this whilst the discussion has been, erm, progressing.
(And I don't like some of the macro games I'm playing, either,
but I'll take the embarassment of that...)

There are many similarities between our approaches - I agree with
you that really there should be no run-time overhead in using
a library doing dimensional analysis (either in speed or size).
Given the type of modelling work we do, this just wouldn't be
acceptable (thousands of iterations over millions of values).

In answer to your favourite question:

    using namespace physical;

    template<class A_Type, class A_Unit>
    quantity<A_Type, d::energy, A_Unit>
    work(quantity<A_Type, d::force, A_Unit> F,
         quantity<A_Type, d::length, A_Unit> dx)
    {
        return F * dx;
    }

where:
 namespace d {
  typedef plus<mass, acceleration>::type force
  typedef dimensional<one, zero, zero, zero, zero, zero, zero> mass;
 }
etc

In normal use, however, it would be used like:
  using namespace physical;
  using namespace physical::si_d; // SI double

  pq_force f = pq_mass(1) * pq_acceleration(34);

  // for mars lander:
  imp_d::pq_force imperialForce = convert_units<imp>(f);

phil

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk