- Boost - lists.boost.org

Fwd: How to build the documentation
by Pedro Larroy 12 Jan '12

12 Jan '12

---------- Forwarded message ---------- From: Pedro Larroy <pedro.larroy.lists(a)gmail.com> Date: Sun, Dec 25, 2011 at 7:35 PM Subject: How to build the documentation To: boost-docs(a)lists.boost.org Hi I created a small patch for libs/python/doc/tutorial/doc/tutorial.qbk How can I check that it builds correctly and generates propper html? Regards. Pedro.

5 8

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 12 Jan '12

12 Jan '12

Vicente, Thank you for your quick reply. I did not get the message from the mailing list, so I copied your questions into this mail. As requested I opened a ticket (ticket# 6377) and I attached the demo application to it, with a small description. > Do you mean that you are not using Boost.thread here? No, the application is running in one thread. The condition variables are used as an alternative sleep method. We discovered that other sleep-methods are even more vulnerable to time changes, and also have different responses to Posix signals. The condition variables continue to work correctly, even with Posix signals, however in combination with time changes there are some issues. In our real application we are using boost threads quite heavily though. > What do you changed exactly? Could you post a patch? I attached the demo application to the issue. It includes the regular Boost condition variable use and the changed implementation. It also includes the Posix timer code to generate the signals. I did not change the Boost code (yet), as I am not that familiar with it. > Please, could you post the test that fails and the one that succeeds, it > will help me a lot. The demo application shows where things go right and wrong, so hopefully you should be able to reproduce the issue. Again, thank you for your quick response. Regards, Johan Borkhuis

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Jan '12

12 Jan '12

On 1/9/2012 12:09 PM, Simonson, Lucanus J wrote: > > > I think that numerical optimization is more general than its application to > machine learning. While you argue that you'd like to see the library go > deep in machine learning I don't see anything wrong with a general purpose > numerical optimization library. However, DE is more general than numerical > optimization, while the library seems to be an application of DE to > numerical optimization. I'm not sure that DE is even one of the best ways > to do numerical optimization (I'm pretty sure genetic algorithm is a bad > way, so I'm skeptical), and I know I'd like a more general interface to a DE > engine than one designed for numerical optimization problems. I'd like to > see the library go wide for max applicability rather than deep. Hopefully > that will keep it out of all the different cans of worms that could be > opened in each application domain. Put numerical optimization and machine > learning applications in the example code of the library and submit just the > core engine as the library itself. Narrowing the scope of a library submission > is usually the path to success. > I forwarded Ken Price (one of the DE co-authors) some of the comments I received for his view on things and here's his reply, which hopefully should clarify some of the issues that have been raised: "The skeptic is right in believing that GAs have traditionally done poorly at numerical optimization, primarily because they rely on general data manipulation operations (bit flips, exchanges, rotations, insertions, replacements...) that are not appropriate for real-parameter optimization. DE, however, was specifically designed for numerical optimization (although it has since been applied with limited success to combinatorial problems). Instead of relying on general data manipulation operations, DE's unique differential mutation operation is a real-valued vector operation that is appropriate for the numerical optimization problem domain. More than just appropriate, the differential mutation operation at the core of DE is effective because it exploits the tendency of a population to distribute itself around function contours. Randomly sampling the difference in the location of population members when they are distributed along a function's level surfaces turns out to be a very effective way to deal with some of the most challenging aspects of numerical optimization, e.g. multiple optima, parameter-dependence, slow-down at high resolution and disparate parameter sensitivities. As evidence of DE's utility as a numerical optimizer, I would offer that it has been part of Mathematica's numerical optimization toolbox for over a decade. It helped the Mathematica team win the SIAM 100-digit challenge (ten problems to ten-digit accuracy) by solving what the contest participants agreed was the contest's most difficult (numerical optimization) problem. (DE also solved one of the other problems in the contest). In the many other contests that have been held to compare numerical optimizers, DE has consistently placed at or near the top. DE is also part of the OPTIMUS package, which is highly respected and in wide use by several automobile manufactures. Alternatively, skeptics can do an Internet search and discover for themselves the enormous range of engineering problems the DE has successfully solved, nearly all of which are numerical optimization problems, often with multiple, non-linear constraints. DE has also proven effective in the domain of multi-objective numerical optimization. Finally, I would suggest that since DE is so simple and easy to implement, skeptics ought to just try it. Most people are surprised by how effective something as simple as DE can be."

2 1

[concept_check] Should OutputIterator check for output_iterator_tag?
by Ronald Garcia 12 Jan '12

12 Jan '12

Hello, In tracking down a problem with Boost.MultiArray, I'd like to write a test case that exhibits the failure. Specifically, certain iterators should be models of OutputIterator, and it's my impression that an output iterator needs to have an iterator_category that's convertible to output_iterator_tag(). However, it looks like the OutputIterator Concept checker in the concept checker library does not check that the output iterator has such an iterator_category. Is that an oversight, or is it not the case that an output iterator have a category that's convertible to output_iterator_tag? It looks like InputIterator, RandomAccessIterator concept checkers perform such a check. Thanks, Ron

3 4

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 12 Jan '12

12 Jan '12

On 1/9/2012 9:41 AM, Brian Schrom wrote: > > On 01/09/2012 09:11 AM, Paul A. Bristow wrote: >>> -----Original Message----- >>> >>> I, for one, think this looks a very useful library. >>> [...] >>> So you may need to find and drum up support from some potential (or > better still, actual) users ? >>> > I will provide a review if this library gets to review, so > far, I've not looked much at this submission. > Thanks. > I think that machine learning is an area where there is enough maturity > that implementations in Boost are desirable. > > A couple of things to consider. > > It would be desirable that the machine learning topic area be > designed a bit more comprehensively than a single library. For example, I > should be able to run a GA on the same data as the DE. I would hope > that they have the same API. This somewhat implies to me that DE/GA are > instances of training algorithms, for which, many are possible. The way I see it, the only common point between different optimization algorithms (if they are generic enough) is the objective function, which should have a very simple prototype: double f( std::vector< double > ); so in theory if different algorithms are implemented to accept the same types (in C++ sense) of objective functions, then you could run them interchangeably between GA, DE etc without any modification to the function or algorithm. > > There are many things that go into a ML solution. Data conditioning, > model training, model validation, model evaluation. Training in > batch modes, instance based, etc. Just to name a couple issues... > > Then the normal list of library desires...completely generic, optimized > for every conceivable configuration (embedded processor, server farm, > etc i.e. single process, multi-threaded, mpi, etc) > > My advice is to be prepared for the big can of worms that this topic could > potentially bring up. > I think the topic area will be a very hard sell, but would be very > useful. > There are many real-life applications that I believe would benefit immediately from a maybe less than perfect implementation, so if it were my choice, I would rather release an initial version sooner and enhance it based on experience gathered from its practical use. Adrian Michel www.tradery.com

2 2

Weak functor: Interested? (How to boost::bind to a weak_ptr)
by Vladimír Třebický 11 Jan '12

11 Jan '12

Hi! I saw people asking how to do boost::bind using a weak pointer. Generally it's not possible without first specifying what should happen if the weak_ptr cannot be converted to shared_ptr. The "weak_fn" I wrote is a small class holding a member pointer, a weak pointer and a "policy": * It is callable so you can insert it to boost::bind. * You can construct it using free function templates. * The policy says what should happen when the object is called yet the weak_ptr cannot be converted to shared_ptr. * It's implemented both using variadic templates and Boost.Preprocessor. Copy of the help comment: /** Returns a callback that can be used eg. in boost::bind. When called, it * tries to lock weak_ptr to get a shared_ptr. If successful, it calls * given member function with given arguments. If not successful, it calls given * policy functor. Built-in policies are: * * "ignore_if_invalid" - does nothing * "throw_if_invalid" - throws "bad_weak_ptr" * "return_default_if_invalid" - returns given value * * Example: * * struct Foo { * void bar(int i) { * std::cout << i << std::endl; * } * }; * * struct do_something { * void operator()() { * std::cout << "outdated reference" << std::endl; * } * }; * * int main() * { * boost::shared_ptr<Foo> sp(new Foo()); * boost::weak_ptr<Foo> wp(sp); * * boost::bind(boost::weak_fn(&Foo::bar, wp), _1)(1); * sp.reset(); * boost::bind(boost::weak_fn(&Foo::bar, wp), 1)(); * boost::bind(boost::weak_fn(&Foo::bar, wp, do_something()), 1)(); * } */ What's missing: * Cannot point to a free function. Only member functions. * ? Wdys? Vladimir.

6 16

Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 11 Jan '12

11 Jan '12

I came across the following issue with condition variables. I don't know if this is an issue with my application or with Boost condition variables. First my setup. I am using Linux on an ARM system, running Boost 1.47. My application needs accurate timing, and for this I use a POSIX timer using SIGRTMIN. This part is not something that I can control, it is an external library that implements this. I use condition variables are a timing mechanism with in my software. When I use condition variables without the POSIX timer there is no problem. The timing continues correctly, even if I change the time forward or backward. When I start the POSIX timer the condition variable does not time-out when I change the time backward. It only times out when the original time (plus timeout) is reached. The code I use to create the condition variable: boost::mutex m; boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); cond.timed_wait(lk, duration); I tested this also by extracting the code from Boost and implementing this inline. This gave the same results. When I changed the clock of the pthread condition variable to monotonic (call to pthread_condattr_setclock(&condattr, CLOCK_MONOTONIC)) the result was OK again. Is this an issue with my implementation, can I change some setting or is this a (known) issue with the Boost condition variables? If people are interested, I do have a small test application that I used to test this issue that I can post here. I don't know however what the policy is on this list wrt posting of attachments. Kind regards, Johan Borkhuis

3 2

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 11 Jan '12

11 Jan '12

Thomas Klimpel wrote: >THOMAS JORDAN wrote: > > Thanks, yes that would be the sensible way to proceed. > > My other question was, though - > > Does Boost::Move library rely on compiler optimisations of > > copy-elision/return value optimisation, as is the case with the Adobe > > Source Library (ASL) Move library, for example. The reason I ask is > > that I suspect the compiler I want to target is not very good at > > said optimisations. Or are there any other known factors which > > could > > mitigate > > against its effectiveness for a. n. other compiler? > Note the RVO (return value optimization) is a feature that is either working > or not, similarly to tail recursion in functional languages. This is unlike > URVO (unnamed return value optimization), which depends on the code > analysis capabilities of a optimizer. (Well, some compilers used to turn off > RVO in debug mode, but this should no longer be the case.) > Writing tests to check whether RVO is implemented is easy. I guess you > have a pretty good chance that even your compiler supports RVO (so I > guess the ASL Move library would work). But this doesn't mean that it will > be easy to get Boost.Move working with your compiler. Actually, just to clarify, I ran some tests which indicate the compiler (Sun C++ 5.10) does RVO on temporaries, but does not do NRVO and also does not seem to do copy-elision (as often as it might, at least). Now the ASL Move library does definitely depend on copy elision to provide any performance benefit, as is stated in its documentation. I tried that library and saw no gain - exactly the same call sequence took place. That seems to make sense I have pulled in the Boost::Move library - actually I only just pulled/hacked in the bare minimum, i.e., the macros and the ::boost::rv class and little else, as I am not so concerned about the C++0x/C++03/platform portability to begin with, just the performance. I got it compiling and running just before I knocked off for the day. It looks like there may be a couple fewer copies than with ASL or than without any move library, but not as much of a reduction as I wanted/expected, though I need to analyse it again more thoroughly tomorrow. It looks from the design of the boost::rv classes and associated overloads, and the conversion operators generated like the macros, that unlike ASL, Boost::Move doesn't rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable assumption? Or is there anything else that people are aware of which could hinder the optimal performance of Boost::Move? Regards, T.

1 0

[range] SinglePassIterator concept check is too strict
by Nathan Ridge 11 Jan '12

11 Jan '12

Hello, It seems to me the concept checking performed by Boost.Range for the SinglePassIterator concept is too strict. In boost/range/concepts.hpp, SinglePassIteratorConcept checks for the following usage (line 157 in trunk): BOOST_DEDUCED_TYPENAME boost::detail::iterator_traits<Iterator>::reference r1(*i); This requires that the return type of operator* be convertible to the iterator's reference type. However, looking at the specification for single pass iterators [1], I don't see any requirement that the return type of operator* be convertible to the reference type - it just needs to be convertible to the value type. An example of an iterator for which the return type of operator* is not convertible to the iterator's reference type is std::istreambuf_iterator<charT>, whose reference type is charT&, but the return type of its operator* is charT. (Both of these are specified explicitly in section 24.5.3 of the C++03 standard.) As a result, code such as the following fails to compile with GCC or MSVC in C++03 mode: #include <boost/range/concepts.hpp> #include <boost/range/iterator_range.hpp> #include <iterator> #include <istream> int main() { BOOST_CONCEPT_ASSERT (( boost::SinglePassRangeConcept< boost::iterator_range< std::istreambuf_iterator<char> > > )); } (In C++11, things changed - a requirement was added that the return type of operator* be the same as the iterator's reference type, and correspondingly std::istreambuf_iterator<charT>'s reference type was changed to be charT). What can be done about this? Regards, Nate [1] http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/new-iter-concepts.ht…

3 2

[context review] Performance questions
by Antony Polukhin 11 Jan '12

11 Jan '12

I`ve read through the documentation of Boost.Context and some questions pop up: 1) What if we reimplement the ASIO example without Boost.Context (server class will look like this): class server : public boost::enable_shared_from_this< server > { private: boost::asio::ip::tcp::acceptor acceptor_; boost::array< char, 1024 > buffer_; void do_() { boost::asio::ip::tcp::socket socket( acceptor_.get_io_service() ); acceptor_.async_accept( socket, boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } void do_1_(boost::system::error_code ec) { if (!ec) { socket.async_read_some( boost::asio::buffer(buffer_), boost::bind( & server::do_2_, this->shared_from_this(), _1, _2) ); } else { do_(); } } void do_2_(boost::system::error_code ec, size_t n) if (!ec) { boost::asio::async_write( socket, boost::asio::buffer( buffer, n), boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } else { do_(); } } } server( boost::asio::io_service & io_service, short port) : acceptor_( io_service, boost::asio::ip::tcp::endpoint( boost::asio::ip::tcp::v4(), port) ), {} public: typedef boost::shared_ptr< server > ptr_t; static ptr_t create( boost::asio::io_service & io_service, short port) { return ptr_t( new server( io_service, port) ); } void operator()( boost::system::error_code /*ec*/, size_t /*n*/) { do_(); } }; Looks like this implementation will be faster (it has the same amount of io_service posted functions, no dynamic allocations, but has no context switches). Am I missing something? 2) Can we use contexts like condition variables? For example: struct task{ }; std::deque void thread_1() void threads

3 7