Boost logo

Boost Users :

Subject: Re: [Boost-users] [phoenix][lambda] lambda to phoenix translation: get sig (signature) from actor
From: alfC (alfredo.correa_at_[hidden])
Date: 2010-05-30 22:50:15


> > which is almost the type I am trying to generate but it is of
> > 'const&' (const reference) type which is a problem for a return type
> > because
> > of 'returning reference to temporary'.
>
> Perhaps just remove ref if you want the value?

yes, I did that

typename remove_reference<typename actor<LambdaExp>::template
result<actor<LambdaExp>(quantity<UnitIntegrandDomain>)>::type>::type

but the syntax is becoming difficult.

> Anyway, I think I need to look more closely. But right now,
> I'm quite full.
sorry if I made you waste your time, and thank you for your help so
far.

> It seems you have it working anyway, no?

yes and no, the argument and the return type are fully translated from
lambda to phoenix
the final result is:
typename remove_reference<
   typename actor<LambdaExp>::template
result<actor<LambdaExp>(quantity<UnitIntegrandDomain>)>::type>::type
        qawc(actor<composite<
                divides_eval, vector<
                        LambdaExp, composite<
                        minus_eval, vector<
                                argument<0>,
                                boost::phoenix::value<
                                        quantity<UnitIntegrandDomain>
>
>
>
> > >
                f_expr,
        boost::numeric::interval<boost::units::quantity<UnitIntegrandDomain>
> const& iv
){

Now the problem is to translate the body of the function,
the original Boost.Lambda version was
                bind(
                        &LambdaExp::template sig<tuple<quantity<UnitIntegrandDomain> >
>::type::value,
                        get<0>(f_expr.args)
(bind(&quantity<UnitIntegrandDomain>::from_value, _1))
                ),
which I can not translate into boost.phoenix, my best try is
        boost::phoenix::bind(
                &remove_reference<typename actor<LambdaExp>::template
result<actor<LambdaExp>(quantity<UnitIntegrandDomain>)>::type>::type::value,
                actor<LambdaExp>(at_c<0>(f_expr))(
                                boost::phoenix::bind(
                                        &quantity<UnitIntegrandDomain>::from_value,
                                        boost::phoenix::arg_names::arg1
                                )
                )
        );
which does not compile ("no match for call to ‘(actor<argument<0> >)
(actor<composite ... )")

On one hand Phoenix seems more powerful than BLL but BLL is more
intuitive to go into the internal works.

> If so, can we get back to this later so I can offer a better library
> solution? I'm very interested with this and how we can do better
> with the current Phoenix-3 rewrite.

Sure, glad you are interested. Let me know if you need more details,
what I am doing now is an experimental code to
interface GSL routines from C++ that uses lambda expression.
Experimental in the sense that I want to see how far I can get with
Phoenix in terms of building a natural (mathematical) language
interface to numerical routines.
In this experimental code
I am trying to make the functions smart enough to recognize *simple*
patterns in the expression.
In this example, it recognizes the singularity (at 3.) in the integral

integral( f( _1 )/(_1 - 3.) , interval(2., 4.));

other simple expressions are

solve( f(_1) == 2.);

just to give you an idea. I am not sure if am repeating someone else's
work but when I see expression templates in C++ I see numerical and
symbolic mathematics converge into the perfect language to do
scientific computing. Of course the patterns do not need to be
necessarily *simple* in the future, once we master Phoenix we can go
beyond to write transformation rules for expression, in order to do
that I must gain complete access to the internal subexpressions and
subexpression types.

Thank you,
Alfredo


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net