[boost] Re: mpl functions, pow_, root_, reciprocal

From: Andy Little (andy_at_[hidden])
Date: 2004-02-01 03:57:50

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ur7xfv7yt.fsf_at_boost-consulting.com...
> "Andy Little" <andy_at_[hidden]> writes:
>
> >> These aren't very interesting metafunctions, since they're all
> >> equivalent to mpl::always<implementation_defined> ;-)
> >
> > Oops sorry perhaps read 'undefined',' user defined' not implementation
> > defined :-)
>
> My point was to say that you are proposing we add something to the
> library,

Whoa ! First I decide against using mpl at all. I was accused of being
'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on
users about how to integrate a power function with mpl. NOTE the "Ideally"
in second line !!! Here is Alexei Gurtovoys reply:

"
Andy Little wrote:
> Hi,

Hi Andy,

> I am implementing the mpl math operators for my physical_quantities type.
> Ideally I would like to declare a boost::mpl::power<A,B> metafunction.
> I would like to do:
>
>         typedef  Power_type<...>  P  ;
>         pq_xx a;
>
>         boost::mpl::power< pq_xx, P >::type    b = run_time_power<P>( a);
>
>        OTOH:  boost::mpl::power< P, pq_xx >::type    b =
> run_time_power<P>( a);
>          (param order ... TBD)
>
> I am assuming it is ok to specialise plus, minus, multiplies etc in the
> boost::mpl namespace?

Yes, totally.

> I could of course put power (or whatever name) outside
> the boost::mpl namespace but that is not ideal. Any thoughts?

If you contribute an implementation for it, I'd be happy to put the
metafunction in the library.

--
Aleksey Gurtovoy
"
> but you haven't shown us anything but a sketch of a few empty
> metafunctions.  How can anyone comment?
I don't know but that doesnt seem to stop you guys! This was not a Proposol
but a tentative question...what if. The next version of pqs will be
available soon. The metafunctions are in!. What namespace to put these
metafunctions in TBD. Meanwhile you may need to use your imagination. It
should not be too hard to understand their purpose surely?. Zounds!.. I
shall write some examples! may lose some accuracy on reciprocal<int_>
!...unless reciprocal< int_>-->rational ... Hmm... found a boost mpl
rational_c :-) ...but no docs :-(
>
> > Not to stay that way just havent had time to write some simple examples.
> > (pow_<int_,int_> should be easy!) Could use one of my own  but doesnt
mean
> > much to many  -->
> >
> > The problem is I have specialised plus, minus, multiplies etc. for use
in
> > 'expression templates'. (think is right term).
> > However it would be odd to put these in separate namespace.
>
> ?? Specializations can only go in the same namespace as the primary
> template.
but not derived :-).
the topic.
1)  Can there be some operators representing power,root and reciprocal in
mpl?. Some other math functions might also be useful... e.g to work around
compile time real calc problems.
2)  If 1), what names can mpl connoiseurs provide? I prefer this type of
thing:
boost::mpl::pow_t<my::my_type,my::my_exp >::type y;
the _t suffix says it returns a type, says its a metafunction, has history
and prevents nameclash with runtime. 4 for the price of 1 :-) It was of
course rejected ... because "One  would consider it a reprehensible
abomination to use such a convention in mpl. It is simply not Done."..etc.
Although no logic followed.
Hmm..hm.hm ... I could do:
plus_t<q_length::m,q_length::mm>::type L;
divides_t<q_length::m,q_time::s>::type  V;
:-)
Seriously though.. Perhaps that may be better because I am not using the
operators to represent a compile-time operation, but the type returned as a
result of the runtime operation... maybe that is an important distinction?
And it would solve the problem...for me anyways:-)
Alternatively reserve mpl namespace for 'operators'.
boost::mpl::math   ?
Whatever you guys decide...meanwhile apologies for trespassing in your
namespace
regards
Andy Little