On 07/11/10 04:11, Alfredo Correa wrote:

I do not understand that. There is a bind example in libs/fusion/example/cookbook/do_the_bind.cpp . Proto might be more helpful here, though.

Speaking of proto, we did make the exercice on writing a Boost.Parameters look-alike using it. https://github.com/jfalcou/boosties/tree/master/options and one of the insight stuff was to not use fusion::map but let proto tree holds the values and make a transform able to extract them based on their ID.

On 11/07/10 23:33, Larry Evans wrote: [snip]

The attached produces output:

[snip]

------------------------------- named/default values for tuple: ------------------------------- at1=ti<1>(1) at2=ti<2>(2) at3=ti<3>(-1) ================================

The args to pairs_nam_ti1_3_t CTOR could be the [snip] Unfortunately, reversing args to airs_nam_ti1_3_t CTOR, as in:

pairs_nam_ti1_3_t pairs_nam_ti1_3_v ( fusion::pair,ti<2> >(2) , fusion::pair,ti<1> >(1) ) causes compile error about "no matching function". Investigating. -Larry BTW, just read: http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html /fusion/notes.html#fusion.notes.overloaded_functions which says: There is an overloaded function, f(k), for each key type k. The compiler chooses the appropriate function given a key, k. which is exactly the method used in named_component_ctor.cpp, where the overloaded function is arg.

On 11/08/10 08:25, Larry Evans wrote: [snip]

Problem solved By adding a templated member function, put, to pairs_named template.

Also, renamed overloaded arg function to at_key, since that's more descriptive.

The attached is a further simplification. Instead of 2 folds, only 1 is used and the resulting structure is really a map, map_default, which allows the user to select which args to specify in the CTOR. One disadvantage is such a CTOR causes a default initialization of some values which are immediately overwritten by the call to put(value_pairs...) in the CTOR. Maybe another disadvantage is inheriting the values(instead of using fusion::vector) consumes more space. Haven't tested. -Larry

On 11/08/10 13:30, Christopher Schmidt wrote:

Larry Evans schrieb:

...

On 11/08/10 06:55, Larry Evans wrote: [snip] [snip]

...

BTW, just read:

http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html /fusion/notes.html#fusion.notes.overloaded_functions

which says:

There is an overloaded function, f(k), for each key type k. The compiler chooses the appropriate function given a key, k.

which is exactly the method used in named_component_ctor.cpp, where the overloaded function is arg.

It's not obvious to me, after looking at:

key_of_impl.hpp value_of_impl.hpp

in boost/fusion/container/map/detail where this overloaded function, f, is located. (Of course I assume it's not named f, but something like value_of...). Could someone point it out?

Larry,

thanks for your work!

Sure. It's interesting.

I am responsible for that change. The old implementation, that is the implementation up to revision 40392, did lookup values by key type via one single overloaded function:

https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/de... https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/de...

I ditched that when I merged associative iterators from my port back to the trunk. I did some benchmarking back then. IIRC, overloaded value lookup did worse than the unrolled value lookup. Here is the original post:

http://article.gmane.org/gmane.comp.lib.boost.user/52510

Another benchmark:

http://article.gmane.org/gmane.comp.lib.boost.devel/194407

I did not use gcc 4.5 and clang back then, though. I will try to get my benchmarks running again and try your implementation.

Regarding the actual topic - reordering on construction has been requested before. Actually we already have a ticket that was opened 3 years ago:

https://svn.boost.org/trac/boost/ticket/1404

I think implementing reordering in fusion::map and fusion::set is not a good idea. At any rate reordering per se does increase compile time and does not fit to the underlying concept of random access (sequence). On the other hand, reordering via fusion::nview is simple. I think it might be a good idea to get this documented, as an example maybe, or in a "useful bits&pieces"-section.

Thanks Christopher; however, I must be misunderstanding what Alfredo wanted. I just thought he wanted named parameters. I thought the example he gave:

One question: Why I can not interchange the order of p and q in the last call, after all it is a map at the library could in principle differentiate the pairs? making it possible to call an unordered named parameter. e.g. cout << H( map, pair >( make_pair<q>(2.), // was p make_pair<p>(1.) // was q ) );

in his OP illustrated that, and I thought my last code example did just that: typedef map_default < mpl::pair,ti<1> > , mpl::pair,ti<2> > , mpl::pair,ti<3> > > map_def_ti1_3_t; ... map_def_ti1_3_t map_def_ti1_3_val2_1 ( fusion::pair,ti<2> >(2) , fusion::pair,ti<1> >(1) ); What am I missing? Thanks much for the explanation and history. That sort of detail sure makes it easier to understand why the code is the way it is. -regards, Larry

On 11/08/10 13:30, Christopher Schmidt wrote:

Larry Evans schrieb:

...

On 11/08/10 06:55, Larry Evans wrote: [snip] [snip]

...

BTW, just read:

http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html /fusion/notes.html#fusion.notes.overloaded_functions

which says:

There is an overloaded function, f(k), for each key type k. The compiler chooses the appropriate function given a key, k.

which is exactly the method used in named_component_ctor.cpp, where the overloaded function is arg.

It's not obvious to me, after looking at:

key_of_impl.hpp value_of_impl.hpp

in boost/fusion/container/map/detail where this overloaded function, f, is located. (Of course I assume it's not named f, but something like value_of...). Could someone point it out?

Larry,

thanks for your work!

I am responsible for that change. The old implementation, that is the implementation up to revision 40392, did lookup values by key type via one single overloaded function:

https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/de... https://svn.boost.org/trac/boost/browser/trunk/boost/fusion/container/map/de...

I ditched that when I merged associative iterators from my port back to the trunk. I did some benchmarking back then. IIRC, overloaded value lookup did worse than the unrolled value lookup. Here is the original post:

[snip] The attached looks like a pretty simple map implementation and may be worth considering. Of course it only works with a variadic template compiler. -regards, Larry

On Sat, Nov 6, 2010 at 2:19 PM, Dave Abrahams wrote:

On Sat, Nov 6, 2010 at 5:19 AM, alfC wrote:

...

(Note, named parameter boost library is not the proper way to go here because the of the level of instrospection I need in the functions, and because the use of named parameters is not to omit passing parameters but to recognize 'externally' certain parameters).

I would be *very* surprised if there was some kind of introspection possible that Boost.Parameter didn't allow. And I don't understand what you mean about omitting passing parameters or external recognition. I think you're reinventing the wheel; a Boost.Parameter ArgumentPack is essentially a fusion map.

ok, since I am probably missing the point, I am going to be one order of magnitude more specific in defining what I want to achieve. In the following example I will mix C++ and mathematical language to make the point clear. In "math", one can define a function of parameters and with some abuse of notation one can use the names of parameters to define functionals (e.g. derivatives), so for example H(p,q) = p*p + q; which can be evaluated, e.g. H(1.,2.) == 3. but one can also "invoke" the derivatives of H, dH/dq(1.,2.) == 4. To be consistent with the abuse of notation one can also say H(p=1., q=2.) or even H(q=2.,p=1), etc. It is this degree of notational flexibility what I would like to achieve. Let's switch to C++ double H(double p, double q){ return p*p+q; } if I call H(1.,2.) I get of course the desired result. I would also like to call something like d(1.,2.) which is the numerical derivative of H with respect to q evaluated at p=1., q=2. That is not possible with the naive definition of H because "q" means nothing in the template parameter of "d". So the next step is to inform C++ of the naming of the parameters, so I did: struct p{}; struct q{}; double H(map, pair > const& args){ return at_key<p>(args)*at_key<p>(args) + at_key<q>(args); // same as return H(at_key<p>(args), at_key<q>(args)); } great, now the compiler has some idea of what the parameters are. I can call this function as H(make_map(1.,2.)); H(make_set(1.,2.)); or even as H(1.,2.) now the derivative problem: suppose I already have a magical templated function, called 'derivative' that returns the numerical derivative of a function or function object, when this function has only one argument. template double derivative(double const& x){ ...already defined... } double f(double x){return x*x;} used as derivative<f>(1.); the question is how to define a function "d" that takes a function like H with fusion container arguments, bind it against all arguments except one and calls derivative on that function. For example d(1.,2.); internally, the code should bind all the parameters except q to its corresponding values in the argument. in this case it is H binded with p=1. and then *derivative* of H( __, 2.) is called with argument 1. Christofere pointed example libs/fusion/example/cookbook/do_the_bind.cpp seems to be in the right direction but the code is hard to read, not to mention that it doesn't compile. Thank you, Alfredo

-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe Boost Users beigetreten sind. Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an boostusers@googlegroups.com. Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an boostusers+unsubscribe@googlegroups.com . Besuchen Sie die Gruppe unter http://groups.google.com/group/boostusers?hl=de, um weitere Optionen zu erhalten.

On Sun, Nov 7, 2010 at 2:11 PM, Larry Evans wrote:

On 11/07/10 13:07, Alfredo Correa wrote: [snip]

...

template double derivative(double const& x){ ...already defined... }

double f(double x){return x*x;}

used as derivative<f>(1.);

the question is how to define a function "d" that takes a function like H with fusion container arguments, bind it against all arguments except one and calls derivative on that function. For example

d(1.,2.);

internally, the code should bind all the parameters except q to its corresponding values in the argument. in this case it is H binded with p=1. and then *derivative* of H( __, 2.) is called with argument 1.

[snip] What about just creating a fusion::vector for tuple containing an initial value, then store that into a templated functor taking the free variable index as one of the template arguments, and then the operator()(double value) would use value to set the tuple at the template index and then call the function. For example:

Hi Larry, I used your free_at.hpp to implement numerical derivative on named parameters of a function object. This post has the final solution that I was looking for: 1) First the "derivable" functor with named parameters, it has this general shape: struct p{}; struct q{}; struct H{ double operator()(double p, double q){ return p*p + q*q; } typedef result_of::make_map< p , q , double, double >::type mapped_arguments; double operator()(mapped_arguments const& args){ return operator()(at_key<p>(args), at_key<q>(args)); } }; The operator()( .. map ..) part is not very elegant. I don't know if it can be improved (suggestions?). 2) Now, how to use the derivative with respect to ONE particular named parameter, this is the notation I wanted to achieve. I think it is decent but I accept suggestions. So, the usage: H h; double uno = 1., dos = 2.; clog << h( uno, dos) << endl; // value at 1., 2., prints 5. clog << d<q>(h)(uno, dos) << endl; // value of derivative at 1.,2. prints 4. // more specific name should be // partial<q>(h) where partial stands for partial derivative Now the internal code that makes the magic in "d", that administers the derivation parameter and ultimately takes the numerical derivative on that function: using namespace boost::fusion; template< class FusionMap, // e.g. fusion::map class Functor, // double(FreeFunction)(FusionMap const&), class FreeArgumentMapKey

struct bind_free_at : Functor, FusionMap{ bind_free_at(Functor const& f, FusionMap const& fm) : Functor(f), FusionMap(fm){} double operator()(typename result_of::value_at_key::type const& free_value){ at_key<FreeArgumentMapKey>(*this) = free_value; return Functor::operator()(*this); } }; template //, class FusionMap> struct d_ { Functor f; template <class Seq> struct result{ typedef double type; }; d_(Functor const& f) : f(f){} typename result<Args>::type operator()(Args const& args) const{ bind_free_at bf(f, args); double x = at_key<ParameterKey>(args); return gsl::derivative::central(bf, x); // this ithe magical function that calculates // the numerical derivative of one-parameter (double->double) function } }; template unfused > d(Functor const& f){ return unfused >( d_(f) ); }; The final code is shorter than what I expected. I think there are some internal redundancies and unnecessary copying but at least it works. Another restriction inherited from fusion::fused is that the d<q>(h) object can only take Lvalues. I hope this helps somebody else, having named derivatives like in mathematical notation is a blessing for my code. Note that I gladly accept suggestions/improvements and that I didn't explore the possibility of using Boost.Parameter because I don't understand that library good enough. Another problem left is that in principle I could also use integer index to define the partial derivative parameter. clog << d<1>(h)( ... ) << endl; // derivative with respect to second (or first??) argument, i.e. equal to d<q>(h)(...) shouldn't be complicated since even if I used named parameters in a fusion map they can bereferenced by integer indeces. Cheers and thanks everyone for your help, Alfredo

On 11/09/10 05:02, Alfredo Correa wrote: [snip]

I hope this helps somebody else, having named derivatives like in mathematical notation is a blessing for my code.

You might try repeating the process on a derivative. IOW, take a derivative of a derivative. I'm sure it would be interesting. [snip]

On Nov 9, 12:53 pm, Alfredo Correa wrote:

On Tue, Nov 9, 2010 at 5:45 AM, Larry Evans wrote:

...

On 11/09/10 05:02, Alfredo Correa wrote: [snip]

...

I hope this helps somebody else, having named derivatives like in mathematical notation is a blessing for my code.

...

You might try repeating the process on a derivative.  IOW, take a derivative of a derivative.

yes, yes. Even crossed derivatives, partial<q>(partial<p>(h))(make_set(1.,2.))

Last night I tryed this and works with some limitations on the way passing parameters to the second derivative.

for the monent I can't use it as partial<q>(partial<p>(h))(uno, dos)

In fact the other threads in the Boost group I opened are to solve this. In a few words, for derivative to have the same interface as H (the model functor) (and automatically generated), I need it to be "fused" and "unfused" at the same time. Which is problematic.

I achieved concatenated (repeated) derivative notation by using variadic templates: given an original functor that can be called as h(1.,2.); //or h(make_map(1.,2.)); you can define the second derivative by repeatedly calling partial<p>(partial<q>(h))(1.,2.); //crossed derivative // or partial<p>(partial<q>(h))(make_map(1.,2.)) partial<p>(partial<p>(h))(1.,2.); //second derivative partial<q>(partial<q>(h))(1.,2.); //another second derivative Note 1: calculating second derivatives in this way is not efficient or numerically stable, there are more efficient ways to calculate second derivatives than. Note 2: fortunatelly partial<...> can be specialized for certain function objects, therefore can contain the *explicit* first derivative of the functor) below is the implementation, the addition with respect to the old is using a variadic operator(): --- using namespace boost::fusion; template< class FusionMap, // e.g. fusion::map class Functor, // double(FreeFunction)(FusionMap const&), class FreeArgumentMapKey

struct bind_free_at{ mutable FusionMap m; Functor f; bind_free_at(Functor const& f, FusionMap const& fm) : m(fm), f(f){} //bind_free_at(bind_free_at const& other) : FusionMap((FusionMap const&)other), f(other.f){} double operator()(typename result_of::value_at_key::type const& free_value) const{ at_key<FreeArgumentMapKey>(m) = free_value; return f(m); } }; template //, class FusionMap> struct d_{ Functor f; d_(Functor const& f) : f(f){} template <class Seq> struct result{typedef double type;}; typedef typename Functor::mapped_arguments mapped_arguments; double operator()(mapped_arguments args) const{ bind_free_at bf(f, args); double x = at_key<ParameterKey>(args); return gsl::derivative::central(bf, x); } template double operator()(DomainTypeS ... domainS) const{ //BOOST_STATIC_ASSERT((sizeof...(DomainTypeS))>1); return (*this)(mapped_arguments(domainS ... )); } }; template d_ partial(Functor const& f){ return d_(f); }; still TODO: improve notation for second derivatives: partial(h)(1.,2.); //second derivative with respect to p