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

From: Cromwell Enage (sponage_at_[hidden])
Date: 2006-01-13 19:38:47

--- Andy Little wrote:
> "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.  Isn't it normally beneficial to
try to limit
> per header dependencies?  What is the rationale
behind adding
> double and big_integral in there too?

It's an unfortunate artefact of the implementation. 
If I could write
numeric_cast<double_c_tag,rational_tag> without using
numerator<double_c_tag>, or write
numerator<double_c_tag> without returning
simplified_rational<big_integral...>, I would.

In the meantime, the main problem we've run into here
is one of granularity.  With integral_c and friends,
you can just

  #include <boost/mpl/integral_c.hpp>
  #include <boost/mpl/plus.hpp>
  ...
  typedef plus<integral_c<long,1>,integral_c<short,2>
>
          three;

Not so with these other numeric constants.  You can't

  #include <boost/mpl/math/rational.hpp>
  #include <boost/mpl/plus.hpp>

without

  #include <boost/mpl/math/rational_/plus.hpp>

One of the two files must include this one.  It's not
going to be plus, so it has to be rational. 
Furthermore, for the moment, I can't be sure which
operations will or will not be used...so I have to
#include them all.

To achieve the finer level of granularity you seek,
then, I need a safe way to #include certain files if
and only if other files are #included, e.g.

  #include <boost/mpl/math/rational.hpp>
  #include <boost/mpl/plus.hpp>

implies

  #include <boost/mpl/math/rational_/plus.hpp>

I'll look into it when I get the chance.

> 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.

It's not *my* double implementation, it's Peder
Holt's, and the metadata are already stored int
BOOST_STATIC_CONSTANTs.

> > 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
don't need
> registration for the vast majority of these types,
also bearing
> in mind that space in the Typeof vector is limited,
so I don't
> think registering everything is a practical way to
do it.

Okay.

> It must be possible for me the user to be able to
register each
> type separately (only if it becomes necessary).  Of
course the
> problem comes then because mpl works in terms of
concepts
> rather than type-names, so I might get an int_, an
integral_c,
> or a long_; a rational or a simplified_rational.  I
don't
> 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 don't think registering everything at one go
is a good
> solution.

If you can ensure that the *only* syntax you use for
any operation (numeric or otherwise) is

  typedef typename some_op<...>::type some_constant;

and not

  typedef some_op<...> some_constant;

then maybe #defining a macro
BOOST_MPL_CFG_TYPEOF_NO_REGISTER_FUNCTIONS will
suffice.

> [snip future plans w/o MPL]

Try to eliminate the use of mpl::vector first, since
it's the biggest slowdown for you.  See if you can
replace it with Boost.Preprocessor constructs.  This
method worked well for me when I gave big_integral an
overhaul.

                              Cromwell D. Enage

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com