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

From: Andy Little (andy_at_[hidden])
Date: 2006-01-14 09:49:23

"Cromwell Enage" wrote

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

The convention of headers  used  with integral_constants is already invalid
because of the use of the mpl::math namespace, therefore I dont see using a
different design as a problem.

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

Once the convention of each boost::math's  types files  having its own directory
is set  I would be quite happy with:

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

BTW What is the purpose of  '_' suffix. on the directory name?

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

As stated above,  just tell the user to get used to the  convention of

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

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

Ok... Apologies to Peder Holt for misattribuing it.

[..]

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

In pqs the typeof interface is comprised of a limited number of types and
certainly not mpl operations .  I would expect  to have the granularity
primarily at the level of each type in the librarys interface. That means a
separate register_X_with_typeof.hpp header for each type. The messy problem of
exactly what type to register  in mpl I now think needs to be left to the user,
because the mpl library author cant know how the user will use the library.

BTW while on the issue of result type of operations

The member ::type of  rational  being a simplified_rational sticks out as being
really odd. and with no precedent in the integral_constants.
As an example of how odd it strikes me ... If this logic was applied to
intgral_constants  then the result type of

mpl::plus<int_<X>,int_<Y> >

would be

added_int<Z>.

OTOH I would expect the  format to be either something like:

template <typename N, typename D>
struct rational{
    typedef  N numerator;       // available for reflection, but no operations
on these here
    typedef D denominator;  //...
    typedef rational type;       // rational is a unary_metafunction
};

// then use  (tediously)

template <typename Rational>
struct simplify_rational{
    typedef  typename apply_simplification_impl<Rational>::type type; // type is
a rational<X,Y>  where eg  '5' /'10'  --> '1'./ '2 'etc
};

IOW  simplification should be an interface operation  to simplify a rational
rather than a distinct user type resulting from the operation.

Or alternatively and  more practical IMO because simplification is be required
before and after any operation anyway (to prevent overflow) it would relieve the
tedium to just do the simplification in place.

template <typename N, typename D>
struct rational{
    impl:
      typedef  detail::simplify_rational_impl<N,D> > impl;
public:
    typedef typename impl::numerator numerator ;
    typedef typename impl::denominator denominator ;
    typedef rational<numerator, denominator> type ;     // simplification in
place
};

IOW I dont see any advantage to making the member ::type of a rational other
than a rational.

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

OK thanks for the tip.

regards
Andy Little