January 2009 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Extending boost::function for mathematics?
by Jesse Perla 29 Jan '09

29 Jan '09

Thanks as always Stephen (who I still refuse to accept is either a single individual or human): Sorry to all if this is getting so long and specific, this project is justified later. Your comments generated a lot of thought about what my main problems are. I think I distracted myself by the generation of derivatives here before I had worked out some other issues. But your implementation looks very elegant. For now lets assume that people supply the gradient/jacobian directly or from their own finite_difference/autodifferentiation. So here are some, more basic, questions. Question 1: Based on your template, how do I forward a function to the boost::function's operator() in this wrapper? Why might we want to do this? Because we are trying to implement a concept with operator() and .gradient(..) with a function wrapper here. Library writers may want to write generic code that operates on any of these, not just ones wrapped in math_function... Then we may end up with true inlining of operator() and .gradient(...) when a full differentiable function object is implemented, instead of always going through an indirection pointer in boost::function. template<class Signature> class math_function { public: typedef boost::function<Signature>::result_type result_type; template<class F> math_function(const F& f, const G& f) : f_(f) : g_(g) {} result_type operator()(How to extract from the signature the input parameters? myvalues...) { return f_(myvalues....); } result_type gradient()(How to extract from the signature the input parameters???????) { return g_(myvalues...); } private: boost::function<Signature> f_; boost::function<Signature> g_; }; void test_mathfunctions() { using lambda::_1; using lambda::_2; math_function<double (double)> myfunc(_1*_1, 2* _1); //simple quadratic cout << myfunc(.1); cout << myfunc.gradient(.1); } Question 2: How can this wrapping interact with binding? void test_mathfunctions_binding() { using lambda::_1; using lambda::_2; //But you might also want a constant thrown in there... Why a separate parameter? Because you don't take the derivative over the other stuff. And you want to keep your functions pure so you can bind, not force them to be stateful, etc. math_function<double (double, double)> myfunc(_1*_1 + _2, 2* _1); //simple quadratic translated by a constant //But how would you work with bind? Would these following work immediately? boost::function<double (double)> myfunc_bound = bind(myfunc, _1, 2.0); boost::function<double (double)> myfuncderiv_bound = bind(myfunc::gradient, _1, 2.0); //or something like this... I always forget member function notation. //Any way to bind that entire structure back to a math_function? Very useful since we would bind parameters before calling optimizers, etc. With dynamic programming we usually have a grid of values and call the optimizer binding over the entire grid. math_function<double (double)> myfunc_bound = math_bind(myfunc, _1, 2.0); cout << my_func_bound.gradient(1.0); //Note that the binding can now use the gradient. } Question 3: How would we adapt a structure implementing the operator() and gradient() to be stored here? Just like boost::function accepting any function object? struct square { double operator()(double x) {return x * x;} double gradient(double x){return 2 * x;} }; math_function<double (double)> myfunc(square); Given the previous code, would we write a constructor like?: template<class F> math_function(const F& f) : f_(f), g_(bind(F::gradient, f, _1...?) //Here I don't see how to bind to the arbitrary signature, extracting the inputs from the Signature which (may) be more than 1 Question 3: What are the thoughts on whether/how this is extensible to higher dimensions? Lets start on the gradient with mapping functions: f : R^N -> R It is perfectly reasonable for these types of problems for the first parameter in the function to be the only one that the derivative is taken over. The dimensionality of the derivative/gradient/jacobian would come out of a combination of the result_type from the signature and the dimensionality of the domain. For example, something like: template<int DomainDim, class Signature> class math_function { public: typedef boost::function<Signature>::result_type result_type; typedef boost::array<DomainDim, result_type> gradient_result_type; //Note that this adds the dimensionality, the data structure could be a template parameter. template<class F> math_function(const F& f, const G& f) : f_(f) : g_(g) {} result_type operator()(How to extract form the signature the input parameters???????) { return f_(Signature); } gradient_result_type gradient()(How to extract form the signature the input parameters???????) { return g_(Signature); } private: boost::function<Signature> f_; boost::function<gradient result_type with OLD INPUT Signature> g_; }; void test_mathfunctions_multidim() { using lambda::_1; using lambda::_2; boost::array<double, 2> mygrad(boost::array<double, 2> x, double a) {boost::array<double, 2> ret; ret[0] = 2*x[0]; ret[1] = 2*x[1]; }; //I put this separately since I don't know how to construct arrays in lambda math_function<2, double (boost::array<double, 2> , double)> myfunc(pow(_1[0]*, 2) + pow(_1[1], 2) + _2, mygrad); cout << myfunc.gradient({{0.0, 0.0}}); //etc. } Question 4: Now lets say that what we really want is to manage f: R^N -> R^M functions. Here, we could potentially use ublas::matrix as a default data structure. template<class Signature, class SecondDimStructure = ublas::matrix, template <class T, int N> class NDimStructure = boost::multi_array > //We really don't need the dim's here since we are using heap based data structures. class math_function { public: typedef boost::function<Signature>::result_type result_type; typedef SecondDimStructure gradient_result_type; //This really is a jacobian, size N * M typedef NDimStructure<result_type::value_type, 4> hessian_result_type; //This really is size (N*M) ^2 if I remember my calculus.... template<class F> math_function(const F& f, const G& f) : f_(f) : g_(g) {} result_type operator()(How to extract form the signature the input parameters???????) { return f_(Signature); } gradient_result_type gradient()(How to extract form the signature the input parameters???????) { return g_(Signature); } private: boost::function<Signature> f_; boost::function<gradient result_type with OLD INPUT Signature> g_; //should add in the higher dimensional hessian of the function if I remember }; Question 5: I want to also associate information about the nature of the function. Whether it is convex/concave, increasing, strictly increasing, etc. These tend to have an inheritance structure, but it isn't absolutely necessary. I was thinking about using trait classes. But I assume that we would lose all those traits when we use type erasure? Are we better off storing a bunch of enums in this data structure? Increasing the size of the class shouldn't be an issue. Question 6: Let me justify why this is all very useful and a general problem: Right now, everyone writing non-linear algorithms in C++ has their own structures for managing mathematical functions that contain derivatives, jacobians, hessians. I am running into this right now because I am trying to wrap a bunch of other people's algorithms for my own work. A few comments: 1) Everyone is using dynamic polymorphism for these overloading a virtual operator() and some type of gradient/jacobian... I assume this is because there is no agreed upon concept for functions objects with gradients... In reality, none of these seem to require dynamic polymorphism. Why shouldn't a newton's method optimizer have inlining of the operator() and derivative through static polymorphism where possible? 2) Most of these guys have conflated functionality/settings specific to their optimizers/solves with the evaluation of the function/gradient. This makes generic code difficult without wrappers/adapters. 3) Many use their own data structures for arrays, matrices, multidim results. This may be inevitable, but means that you need to have these types parameterized in any mathematical callback routine. 4) While a lot could be gained from having people agree on a static concept for mathematical applications akin to standardizing on operator() for functors, it is also very useful to have a generic callback wrapper akin to boost;:function. The main reason for this is that you will tend to write parameterized, pure functions where you want to bind parameters. Worst case, people could write their own functions with this mathematical callback structure and adapters could be written for the different libraries. 5) Not to disparage these superb libraries, but a few examples to see what I mean: http://quantlib.org/reference/class_quant_lib_1_1_cost_function.html and http://trilinos.sandia.gov/packages/docs/r6.0/packages/didasko/doc/html/nox… and http://www.coin-or.org/CppAD/Doc/ipopt_cppad_simple.cpp.xml If anyone is interested in working with me on this very interesting and useful problem, please give me an email. I think it has a lot of potential for general use. -Jesse

11 19

Re: [Boost-users] Boost and K-Cuts
by Gianni Loiacono 29 Jan '09

29 Jan '09

Hi mr. Zeljko Vrba, I have downloaded and readed the soruce file for build the GoHu tree. It uses a different implement approch from Boost....;°( I don't understand very well the source, but I have understand that if I want to add it to my project I must "revolutionize" my source :( :( Sorry for my eng. ;) Bye.

1 0

Re: [Boost-users] top posting, was boost::proto helpful for a compiler project?
by raindog＠macrohmasheen.com 29 Jan '09

29 Jan '09

I know its a rule, but I think it is dumb. My phone does not even support botting posting for example, does that mean I'm not allowed to post to this newgroup? my guess is that it started off with a few people wanting to separate themselves from others by usage of arbitrary rules in order to obtain some form of "l33tn3$$" without having actually considering the merits or lack thereof ubtil after their motives were question in which scenario artificial ones were created to support the habbit. Modern mail clients (my phone not one of them) support threaded mail anyways and so what you get is the same email. 100 times in a thread. There has been the argument that if you were ob a forum that they go by bottom posting but again modern mail clients support threading anyways, and I don't know about you, but I can't recall the last time I was reading a forum and every post included included the entirety of the posts to the thread prior. Lastly, why would you ever want to pick up a thread by reading the middle of it? Using the forum analogy, one would be hard pressed to find someone whose month was to always read a thread by starting on page 12, so, group by thread and read from the start ------Original Message------ From: Eric Niebler Sender: boost-users-bounces(a)lists.boost.org To: boost-users(a)lists.boost.org ReplyTo: boost-users(a)lists.boost.org Sent: Jan 26, 2009 4:42 PM Subject: Re: [Boost-users] boost::proto helpful for a compiler project? Please don't top-post. See http://www.boost.org/community/policy.html#effective peter_foelsche(a)agilent.com wrote: > Eric Niebler wrote: >> peter_foelsche(a)agilent.com wrote: >>> How can boost proto help me in my compiler project? >>> >>> Is it another way to write a grammar and parse it? >> >> If by "compiler" you mean something that reads a text file, parses >> it according to a grammar and Does Something, then Proto is *not* >> what you are looking for. Use Boost.Spirit. >> > ok. Can you give me an application area for boost::proto? In short I > don't understand what DomainSpecificEmbeddedLanguage means. The term is defined in Proto's documentation, and many examples are given there. http://boost-sandbox.sf.net/libs/proto HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Sent from my Verizon Wireless BlackBerry

6 5

Boost.Parameters: are static member functions possible somehow?
by Joost Kraaijeveld 28 Jan '09

28 Jan '09

Hi, I can generate global and ordinary member functions with Boost.Parameters. But I would like to create static member functions. IS that somehow possible? I have looked at the macros of the library but I did not get any wiser :-(. So is it possible, and if so, how? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl

2 1

Install on Mac OS
by rolf ngondo 28 Jan '09

28 Jan '09

Hi all! I'm developping an application using boost on MAC OS X, using CMake as system compiler. I succesfully built the same application with CMake on windows and it works fine. But on Mac OS, the build fails. It sounds like CMake failed finding boost include directory. I tried the bjam command : bjam --builddir=anydir --toolset=gcc --with-some_boost_lib install. I got libs but it skipps creating any directory on /usr/local/. If anyone succeeded on installing boost properly in /usr/loal... please help. One more thing, since I'm using CMake, I can't use boost version later than 1.36.0. Thanks to all.

3 5

[BGL] - deriving from filtered_graph
by Michael Fawcett 28 Jan '09

28 Jan '09

When using a type that I derived from filtered_graph, if I use operator[] on the instance, e.g. derived_from_filtered_graph_instance[descriptor].foo = bar; I get the following error: C:\dev\vendor\boost\1.37.0\boost/graph/graph_traits.hpp(124) : error C2039: 'edge_bundled' : is not a member of 'btra::restricted_graph<Graph>' 1> with 1> [ 1> Graph=btra::undirected_graph 1> ] 1> C:\dev\vendor\boost\1.37.0\boost/graph/graph_traits.hpp(137) : see reference to class template instantiation 'boost::edge_bundle_type<G>' being compiled 1> with 1> [ 1> G=btra::restricted_graph<btra::undirected_graph> 1> ] 1> C:\dev\btra\trunk\btra/two_way/esri_io.h(186) : see reference to class template instantiation 'boost::graph::detail::bundled_result<Graph,Descriptor>' being compiled 1> with 1> [ 1> Graph=btra::restricted_graph<btra::undirected_graph>, 1> Descriptor=boost::detail::edge_desc_impl<boost::undirected_tag,__w64 unsigned int> 1> ] and if I typedef edge_bundled in the derived class, everything seems to work okay. filtered_graph doesn't contain the typedef, the Graph type does, so does this mean that to be more correct I should specialize graph_traits for my derived type, or is just having the typedef enough? Also, in the filtered_graph documentation, it says it models VertexAndEdgeListGraph and PropertyGraph, but neither of those concepts mention edge_bundled as an associated type. Thanks in advance, --Michael Fawcett

2 3

[serialization]Runtime Exception While Loading Old Serialized XML Files w/ 1.38
by Yaser Zhian 28 Jan '09

28 Jan '09

Hello list, I have a bunch of XML files that have been serialized using Boost.Serialization (the standard XML archive) and were working fine until we upgraded to the boost trunk a few days ago (unfortunately, I can't tell exactly what repository revision were used to generate the archives, but I know they were custom builds of pre-release 1.37 trunk, and the file_version attribute in the XML is set to 4.) Also, we use MSVC9.0sp1 for building everything. As soon as we upgraded to the trunk, we started getting runtime exceptions (invalid archive format) on some of our larger files. I think I have tracked it down to an incompatibility between version 4 and version 5 files that the newer build fails to take into consideration, the details of which (as far as I could find out) follows. In our data structures there is an std::list of pointers to objects previously serialized in the same serialization operation (which means these repeated pointers are stored as a reference to the previous object and the data is not duplicated.) Using the old library, when this list was being serialized, apparently the "item_version" was not being written (only the "count" filed and the "item"s were.) The old library apparently didn't expect to read this either, so everything worked out nicely. The new library however, expects an "item_version" field and throws when it doesn't find one. As I trace into the serialization library, I can see that there is logic there for new libraries to be able to handle archive format changes through time. Now my question is whether this "discrepancy" is actually a bug in either the older or the new code, or failing to handle the format change is a bug, or this issue has already come up and been dealt with in some other way? (how?) I should also mention that it is quite probably that the problem be in our code, but I have no idea how. I would appreciate any help in locating it. Any pointers, help, clues and general wisdom is greatly appreciated. -yzt

2 3

need help building boots
by Vincenzo Calo' 28 Jan '09

28 Jan '09

Hi, my log file was scrubbed in my previous post. So I'm posting it again, sorry. I'm a newbie and I'm trying to build boost on a Mac OS X 10.4.11. I'm not able to generate the dylib files so something is going wrong. dhcp25:/usr/local/lib/boost_1_37_0 root# ./configure --with- libraries=iostreams Building Boost.Jam with toolset darwin... tools/jam/src/bin.macosxx86/ bjam Unicode/ICU support for Boost.Regex?... not found. Backing up existing Boost.Build configuration in user-config.jam.4 Generating Boost.Build configuration in user-config.jam... Generating Makefile... dhcp25:/usr/local/lib/boost_1_37_0 root# make install ./tools/jam/src/bin.macosxx86/bjam --user-config=user-config.jam -- prefix=/usr/local --exec-prefix=/usr/local --libdir=/usr/local/lib -- includedir=/usr/local/include --with-iostreams install ...patience... ...found 14372 targets... ...updating 21 targets... MkDir1-quick-fix-for-unix bin.v2/libs/iostreams MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build/darwin-4.0.1 MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build/darwin-4.0.1/ release MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build/darwin-4.0.1/ release/threading-multi darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi/file_descriptor.o /var/tmp//cc3iqlUI.s:7843:Complex expression. Absolute segment assumed. /var/tmp//cc3iqlUI.s:7845:Complex expression. Absolute segment assumed. /var/tmp//cc3iqlUI.s:7850:Complex expression. Absolute segment assumed. /var/tmp//cc3iqlUI.s:7852:Complex expression. Absolute segment assumed. /var/tmp//cc3iqlUI.s:7856:Complex expression. Absolute segment assumed. ... "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline - Wall -dynamic -no-cpp-precomp -gdwarf-2 -Wno-long-double -fPIC - DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DNDEBUG -I"." -c - o "bin.v2/libs/iostreams/build/darwin-4.0.1/release/threading-multi/ file_descriptor.o" "libs/iostreams/src/file_descriptor.cpp" ...failed darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/ release/threading-multi/file_descriptor.o... darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi/mapped_file.o /var/tmp//ccuFxoHi.s:15391:Complex expression. Absolute segment assumed. /var/tmp//ccuFxoHi.s:15393:Complex expression. Absolute segment assumed. /var/tmp//ccuFxoHi.s:15398:Complex expression. Absolute segment assumed. /var/tmp//ccuFxoHi.s:15400:Complex expression. Absolute segment assumed. .... "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline - Wall -dynamic -no-cpp-precomp -gdwarf-2 -Wno-long-double -fPIC - DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DNDEBUG -I"." -c - o "bin.v2/libs/iostreams/build/darwin-4.0.1/release/threading-multi/ mapped_file.o" "libs/iostreams/src/mapped_file.cpp" ...failed darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/ release/threading-multi/mapped_file.o... darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi/zlib.o darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi/bzip2.o ...skipped <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi>libboost_iostreams-xgcc40-mt-1_37.dylib for lack of <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/threading- multi>file_descriptor.o... ...skipped <p/usr/local/lib>libboost_iostreams-xgcc40-mt-1_37.dylib for lack of <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/ threading-multi>libboost_iostreams-xgcc40-mt-1_37.dylib... ...skipped <p/usr/local/lib>libboost_iostreams-xgcc40-mt.dylib for lack of <p/usr/local/lib>libboost_iostreams-xgcc40-mt-1_37.dylib... MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static MkDir1-quick-fix-for-unix bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static/threading-multi darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ link-static/threading-multi/file_descriptor.o /var/tmp//ccgEKwgZ.s:7843:Complex expression. Absolute segment assumed. / "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline - Wall -no-cpp-precomp -gdwarf-2 -Wno-long-double -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static/threading-multi/file_descriptor.o" "libs/ iostreams/src/file_descriptor.cpp" ...failed darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static/threading-multi/file_descriptor.o... darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ link-static/threading-multi/mapped_file.o /var/tmp//ccDow0aV.s:15391:Complex expression. Absolute segment assumed. /var/tmp//ccDow0aV.s:15393:Complex expression. Absolute segment assumed. /var/tmp//ccDow0aV.s:15398:Complex expression. Absolute segment assumed. /var/tmp//ccDow0aV.s:15400:Complex expression. Absolute segment assumed. /var/tmp//ccDow0aV.s:15404:Complex expression. Absolute segment assumed. /var/tmp//ccDow0aV.s:35405:Complex expression. Absolute segment assumed. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline - Wall -no-cpp-precomp -gdwarf-2 -Wno-long-double -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static/threading-multi/mapped_file.o" "libs/iostreams/ src/mapped_file.cpp" ...failed darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/ release/link-static/threading-multi/mapped_file.o... darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ link-static/threading-multi/zlib.o darwin.compile.c++ bin.v2/libs/iostreams/build/darwin-4.0.1/release/ link-static/threading-multi/bzip2.o ...skipped <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/link- static/threading-multi>libboost_iostreams-xgcc40-mt-1_37.a for lack of <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/link-static/ threading-multi>file_descriptor.o... ...skipped <p/usr/local/lib>libboost_iostreams-xgcc40-mt-1_37.a for lack of <pbin.v2/libs/iostreams/build/darwin-4.0.1/release/link- static/threading-multi>libboost_iostreams-xgcc40-mt-1_37.a... ...skipped <p/usr/local/lib>libboost_iostreams-xgcc40-mt.a for lack of <p/usr/local/lib>libboost_iostreams-xgcc40-mt-1_37.a... ...failed updating 4 targets... ...skipped 6 targets... ...updated 11 targets... Not all Boost libraries built properly. Thanks a lot for your help. Best, Vincenzo

1 0

help building boost
by Vincenzo Calo' 28 Jan '09

28 Jan '09

Hi, I'm a newbie and I'm trying to build boost on a Mac OS X 10.4.11. I'm not able to generate the dylib files so something is going wrong. I've attached the output log file. Thanks a lot for your help. Best, Vincenzo

2 1

[date_time] new local_date_time constuctor
by a k 28 Jan '09

28 Jan '09

Hi, This is a request to add a third constructor of the class boost::local_time::local_date_time. THE PROBLEM: The following piece of code throws an exception. date d(2008, Oct, 26); time_duration td( 2, 30, 0 ); // 2:30 a.m. time_zone_ptr tz( new posix_time_zone("CET-1CEST,M3.5.0,M10.5.0/3") ); local_date_time myLtime( d, td, tz, EXCEPTION_ON_ERROR ); // last line throws This is because the date and time I chose happens to be located in the "vulnerble" moment when the wall clock gets moved back by an hour. In human terms, time 2:30am appears twice on 26-Oct-2008 in CET time zone because at 3:00 am we go back to 2:00 am and arrive at point 2:30 once more. In terms of boost::date_time library, the following condition appears: (local_date_time::check_dst(d, td, tz) == ambiguous); I would like to be able to write something like "On creating date/time infer the DST flag; on ambiguity assume no DST". In fact I can do that currently by replacing the last line from my above example with: bool inDST = (local_date_time::check_dst(d, td, tz) == is_in_dst); local_date_time myLtime(d, td, tz, inDST); This has two drawbacks however. First, check_dst gets called twice: first by me, second by the constructor, to check it once more. Second, it is too (IMO) verbose. THE REQUEST: Would it be possible to add a third constructor of local_date_time class that would accept a hint how to solve an ambiguity (if we have one). It would read like: local_date_time myLtime( d, td, tz, ASSUME_NOT_DST_ON_ERROR ); In the boost code I found it was already thought of, but got into a TODO state. Is there any chance that it gets implemented? Regards, &rzej

1 0