Re: [boost] [MPL.Math] Updated version now available

From: Andy Little (andy_at_[hidden])
Date: 2006-01-13 15:03:40

"Cromwell Enage"  wrote

> I've added <boost/mpl/math/rational_/rational.hpp>,
> which contains the minimal amount you need to use only
> boost::mpl::integral_c et. al. and
> boost::mpl::math::rational.  The
> <boost/mpl/math/rational.hpp> header is reserved for
> those who need the kitchen sink.

That seems like an odd way to do things. I would expect the main header for
rational to just contain the interface for rational itself. Isnt it normally
beneficial to try to limit per header dependencies? What is the rationale behind
adding double and big_integral in there too?

[...]

>> Anyway changing the gcd algorithm to a recursive one
>> wrapping boost::math::static_gcd (attached) in
>> "boost/math/commn_factor.hpp" cures the above
> problem of
>> compiler running out of keys and similar issues for
> me.
>
> I've reimplemented the integral_c_tag specialization
> of boost::mpl::math::gcd so that it's wrapped around
> an MPL-ized version of boost::math::static_gcd.
> Performance should be close to what you're looking
> for.
>

That looks a lot  better. (Once I've waded through the macros). I'm not sure if
you use rational with mpl integral constants in your double implementation, but
if you do that mod should help compile times a there too.

>> As previously mentioned I also reckon that it would
> be best to
>> make typeof registration separate.
>
> I thought you said "optional".  Anyway, typeof
> registration is now disabled by default; you must now
> define the macro BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to
> enable it.

For each type, typeof registration is quite a heavyweight process, so I want to
only register those types that I Really need to.  Currently this is not the case
so I get for example mpl::math::zero, mpl::math::denominator, etc etc, etc, etc
and the kitchen sink registered for me though I dont need registration for the
vast majority of these types, also bearing in mind that space in the Typeof
vector is limited, so I dont think registering everything is a practical way to
do it.

It must be possible for me the user  to be able to register each type separately
(only if it becomes necessary.)
Of coures the problem comes then because mpl works in terms of concepts rather
than type-names,  so I might get a int_, a integral_c, or a long_.  , a
rational or a simplified_rational.  I dont really know a clean  solution to the
problem of what to register if I use mpl, (maybe  'per concept registration
would be OK) but I dont think registering everything at one go is a good
solution.

Throwing the baby out with the bathwater.

Having come up against  compile times/debris problems in mpl as applied
specifically to the pqs library ( mostly due to mpl::vector),  In pqs_3_0_1, as
an alternative style to the mpl way, I am currently thinking in terms of how to
use  the minimum variety of types, parameters and functions etc.  This line of
thinking means for instance that I would have a  (custom for the pqs library)
rational<1,2> , note not rational_c<int,1,2> or rational<int_<1>,long_<2> >. and
also no conversion via the tag system between rational and int_ for instance. I
can use boost::is_same rather than mpl::equal_to for comparison, which
represents another reduction in complexity as well as a reduction in potential
number of types created automatically.  Similarly result of an operation on two
rationals will be a rational, so that I can use boost::is_same for comparison of
types comprised of rationals, have a definite 'type' interface and a known
documentable  type as result of operations and reduce the number of types
requiring Typeof registration. IOW I have decided to abandon use of mpl entirely
in the next version of pqs library and see if that helps specifically with the
compiler out of keys issue (which I am still getting  currently when using
headers with a lot of physical_quantity types) and the compile time issue. These
are greater  problems in pqs than some other uses of mpl because the idea is to
be able to use these types to 'seamlessly' replace bult-in types such as double
and int. That means absolutely minimal effect on compilation time and of course
minimal use of compiler resources too.

regards
Andy Little