- Boost - lists.boost.org

Automatic differentiation (and complex numbers) with lazy component evaluation
by Hal Finkel 27 Apr '10

27 Apr '10

Hello, I've uploaded to a subversion repository on SourceForge my Lazy Types library. This library provides template classes for dual numbers (used for automatic differentiation) and complex numbers. Expression templates are used in order to evaluate only those components which are actually needed. All of the standard-library math functions (and arithmetic operators) are supported. http://lazytypes.sourceforge.net/ http://sourceforge.net/projects/lazytypes The dual-number formalism is especially useful because it enables the compiler to generate analytic expressions for the derivative of "any" function (where "any" is restricted to those functions which compute using operators and functions the library knows about, which include all of the standard ones). These are *not* finite-difference approximations, but exact answers (to machine precision). Functions which use conditional statements, loops, etc. are fine, although the derivative might not have a meaning if evaluated at a point of discontinuity. This code has been released under the BSL 1.0. Although some Boost headers are used (enable_if, type_traits, etc.), Boost.Proto is not used. Is there any interest in having these libraries in Boost: 1. As-is (plus more documentation, tests, namespace change, etc.) 2. Only if rewritten to use Boost.Proto (which I am willing to do, so long as the performance of the current implementation can be matched). The project Wiki page (to which http://lazytypes.sourceforge.net/ redirects) has some documentation and usage examples. Here is a quick example of taking the derivative (and the second derivative) of a multivariate function: #include <lazy_types.hpp> namespace lt = lazy_types; ... template <typename X> X f(X &v1, X &v2) { using namespace lt; return pow(v1, 3) + pow<3>(v1) + pow<2>(v2 + v1) + v2*v1/5.0 + 3.0; } // A pow<> template is provided which works with the expression-template types. ... lt::dual<double, 2> fv1(2.0, 0), fv2(4.0, 1); lt::dual<double, 2> fv = f(fv1, fv2); std::cout << fv << " " << fv.eps(0) << " " << fv.eps(1) << std::endl; // This computes the derivative of the function f with respect to both of its arguments evaluated at the point where the function itself has been evaluated. // An example of computing the second derivative: template <typename X> X df(X &v1, X &v2, size_t ei) { lt::dual<X, 2> d1(v1, 0); lt::dual<X, 2> d2(v2, 1); return f(d1, d2).eps(ei); } lt::dual<double, 2> df0 = df(fv1, fv2, 0); lt::dual<double, 2> df1 = df(fv1, fv2, 1); std::cout << df0.eps(0) << " " << df0.eps(1) << std::endl; std::cout << df1.eps(0) << " " << df1.eps(1) << std::endl; If there is interest in adding these types (or some rewritten version of them) to Boost, please let me know, and I'll work on getting the library ready for review. Sincerely, Hal Finkel

3 4

[asio] how to handle "boost::asio::placeholders::error" in "boost::function"?
by 曹亚文 26 Apr '10

26 Apr '10

Hi all, I met a problem which can't be solved. Can any kind people help me? The code looks like the below: class transfor_data { public: void one_fun( const boost::system::error_code& e, connection conn ) { ... } void another_fun() { { //compile error because of the placeholder boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, boost::asio::placeholders::error, conn); } { //fine without placeholder boost::system::error_code e; boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, e, conn); } } }

3 2

[shared_ptr] Bug in perfect forwarding test?
by John Maddock 26 Apr '10

26 Apr '10

Now that rvalue refs are enabled for VC++10 the perfect forwarding test fails: http://tinyurl.com/367o3ab This looks like a legitimate failure to me, as the constructor to Y requires an "int&" non-const reference, but the make_shared_ptr function passes a "const int&". Ah... actually this may be to do with the fact that the header is predicated on BOOST_HAS_VARIADIC_TMPL as well as BOOST_HAS_RVALUE_REFS where as the test case is only predicated on BOOST_HAS_RVALUE_REFS? BTW there's an rvalue-refs related failure with gcc-4.5 in C++0x mode as well: http://tinyurl.com/37quwbj Cheers, John.

2 1

[1.43] Wrong version in version.hpp
by John Maddock 26 Apr '10

26 Apr '10

Just a note to point out that the release branch still has the version number set to 1.42 in boost/version.hpp. John.

2 1

[async] messages threads and networks
by Scott Woods 26 Apr '10

26 Apr '10

Hi Boost, Is anyone interested in a framework for asynchronous programming? This is based on the thinking contained in; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) SDL is the ITU standard for specification of signaling systems. AO is a pattern for concurrent programming. These have been combined to create an environment where objects exchange messages, possibly between threads or even over networks. Objects are created simply; id = create<object_type>(); and once created, anything can be sent to it; send( anything, id ); The framework takes care of threading, network addresses, queueing, encoding and optimal I/O, as appropriate. Threads are equally simple to create; p = start<message_processor>(); and objects can be assigned to specific threads at creation time; id2 = create<object_type>( p ); A network server can be created as simply as; listen = create<socket_listen>(); server = create<socket_server<my_server> >(); service operational( "loopback:5500", server ); send( operational, listen ); Connecting is equally simple; connect = create<socket_connect>(); client = create<my_client>(); service operational( "localhost:5500", client ); send( operational, connect ); >From that point on, client and server can exchange messages using the send primitive without any knowledge that messages are actually travelling across a network. There is in fact no difference between inter-thread messaging and inter-processes (i.e. for the application). Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web I am interested in a Boost review of this library but suspect it is too large. It also overlaps with several existing boost components. But good to get further opinions. Cheers, Scott

5 18

[Interprocess] Patch: Various standard-conformance fixes
by Doug Gregor 26 Apr '10

26 Apr '10

The attached patch contains several fixes to improve the interprocess library's conformance to the C++ standard. The fixes are: - Added two missing "template" keywords where the left-hand side of a member access (with ->) is dependent - Removed a "mutable" from a reference type in two places - Removed an extra space from the end of the file name in INCLUDE_BOOST_CONTAINER_MOVE_HPP - Doug

2 1

[Iterators] Iterators and higher-order programming
by Thomas Jordan 25 Apr '10

25 Apr '10

Hi, One of the interesting things about the iterators library, it seems to me, is the additional support it gives for higher-order, functional-style programming. For example, you can use the transform and filter iterators to produce a simple 'Comprehension' object which permits list-comprehension type of syntax to be used, instead of conventional loops (or, e.g., std::transform). I found this quite exciting. I guess I could have come across this nice library sooner if it had been called 'Higher-Order Iterators' or at least co-categorised under the Function Objects and Higher-Order Programming library category. Anyway, is the the intention that we now have a 'computationally-complete' alternative to loops, with which we can write general loops in a more functional, type-ful way? Regards, Tom

2 1

[type_traits] optimized std::copy example wrong?
by Thorsten Ottosen 25 Apr '10

25 Apr '10

Hi John & co, IIRC, std::copy() cannot use memcpy(), since the memory is allowed to overlap. Therefore it can only use memmove(). regards -Thorsten

5 5

[1.43][Serialization] Serialization library seriosly broken
by Hartmut Kaiser 25 Apr '10

25 Apr '10

As I alluded to in my mail yesterday, the serialization library seems to be utterly broken in the current trunk, and unfortunately in the current release branch as well. We're seeing assertions at application initialization time during serialization registration in the file void_cast.hpp, line 225. That is in debug builds. In release builds we're seeing aborts later on. These problems seem to be caused by registering the same type more than once but from different shared libraries. We do not intentionally register the types more than once, even more, we have no control over this. Here is the simplified code causing the multiple registrations from different modules: struct Parameter_impl : ::Par // ::Par is a C-struct { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & lambda; ar & allowedl; // more serialization going on } }; struct Parameter { boost::shared_ptr< Parameter_impl > p; // ... private: friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & p; } }; Note: no BOOST_..._EXPORT or other serialization macros are utilized in this file. This code is included by several files from different shared library modules as it is passed around. It is just including this file into compilation units from different shared libraries what causes the problems described above. All code worked before and still does with V1.42. If this error stays in the release branch the whole Boost release will be unusable for us, causing endless grief in the future. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

6 13

[tokenmap] updated perfect hash container in sandbox
by Slawomir Lisznianski 25 Apr '10

25 Apr '10

Changes: * To eliminate a possibility of the algo for finding free slots becoming slower as the load factor increases, the container now keeps track of open slots in unused nodes. This guarantees constant time insertion of new elements at a slight bookkeeping overhead. Consequently, the load-factor has been removed. Pointed by Daniel James. * More STL compliant (iterators, size(), empty(), etc)

4 9