December 2011 - Boost - lists.boost.org

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

12 Dec '11

On 12/12/2011 7:19 AM, Sebastian Redl wrote: > Your website went down, it redirects the webhost's site. My apologies - I ftp-ed an updated version of the documentation with the wrong structure - instead of it being located at .../de/doc/html/... it was at .../de/html, as Thomas Kimpel noted in his reply. It should work again shortly. Also, I realized posting urls for individual documentation pages was a mistake, as I don't believe doxygen guarantees they will stay the same as the documentation evolves, so if you notice any errors when accessing the Overview or Tutorial urls, try the documentation home page http://www.amichel.com/de/doc/html/. Thanks both. Adrian

1 0

A demonstration of why horrendous error messages can destroy usability
by Gregory Crosswhite 12 Dec '11

12 Dec '11

At the unfortunate risk of reopening a poisonous argument, I just wanted to relate an experience I had just earlier today to emphasize a point that I and others tried to make a couple of weeks ago. For the last couple of days I have been trying to get Digikam to compile on my machine using MacPorts. Getting software written for Linux to compile on OSX is always a bit of a black art, so I wasn't surprised when I started running into hurdles. The first problem that I ran into was that I had set Python 3.1 to be my default rather than Python 2.7, which screwed up the libplist CMake configuration script; fortunately, although I had to scratch my head for a few minutes, it was clear roughly where the error was taking place and that gave me enough information to eventually figure out where the problem was. I also went ahead and filed a bug report to MacPorts to let them know about this problem. After that it was smooth sailing until I got to the final package, Digikam itself. Unfortunately, it refuses to build. Why is that? For reasons that apparently took an overwhelming *56 kilobytes of error message* to explain. (See attached, if you dare. ) Now, you could argue that this is the fault of the compiler for not being more helpful, the fault of Digikam for using deprecated methods, the fault of MacPorts for creating a bad environment for configuration, or whatever else you want. You could also argue that were I familiar with Boost and/or the Digikam codebase then the implication of this message would be obvious --- heck, maybe it even *is* obvious to many of the people here. All of this is beside the point, though. I am not an expert in any of these codebases and I really don't care whether it is ultimately the fault of Boost, Digikam, Qt, MacPorts, or the compiler for producing such horrendous error messages. All that matters to me is that these pages of error messages are so overwhelming that they make it very difficult for me to get any sense at all of what kind of thing is going wrong so that I can track down what needs to be done to fix it. Furthermore, the error message is such a mess that it is hard for me to even *motivate* myself to *want* to go through it to figure out where is going on, and seeing the impact that this kind of thing can have on end users really turns me off a bit from the idea of continuing to use Boost libraries in my projects in the future. That is to say, I had heard people in the past say that they actively avoid Boost (and sometimes even C++) because of the way they introduced nasty complexities (like horrible error messages), and I used to (politely :-) ) scoff at them because I figured that they were overstating the problems in practice. Now however, having experienced these problems from the viewpoint of a casual user who just wants to get some darn code to compile so that I can run a program I wanted to try out, I can really appreciate their point. To be perfectly clear, I am not saying that this has made me never want to use Boost again, for I really hate rolling out my own code to solve a problem when somebody else has already developed and tested a solution for me. :-) My point is exactly and *only* the following: horrendous error messages are a *big deal* with a *serious impact* on usability not only for the developers using a library, but for end-users who want to compiler and use the software being developed. Most people here fortunately already seem to recognize this, but I have been truly shocked to hear so many arguments that horrendous error messages are *not* a serious problem, either because they are someone else's fault, because they only occur when the code is wrong, or --- worst of all --- because it is ultimately the fault of the user for being ignorant or lazy when he or she cannot quickly figure out what the problem causing the message was. So I just wanted to share this anecdote to provide a real-world example where horrendous error messages have added an incredible cost for a relatively technically experienced end-user to actually use a particular piece of software. And once more, I am sorry to bring this tired point up again, it's just that the experience I had today really reminded me just how frustrating these kinds of error messages can be, and the absurdity of denying that this is in any way a problem. I feel very strongly that the ultimate goal of writing software is not merely to push the boundaries of what we can do but to provide people with tools that make their lives easier. Horrendous error messages, even when there is no better design to accomplish a particular task (in C++, at least), are *really bad things* and should *not* be dismissed as something not worth fussing about, *especially* when fault is then placed on the *user* (as in some cases it sadly seemed to be) for being too ignorant or lazy to be willing to go to the trouble to decipher them. I am not claiming to know what the solution is to these kinds of issues, and in many cases there might not even be better solutions given the current design of C++. I was just very concerned to see that in the eyes of many the presence of such error messages are not considered in any way to be a problem (*) with a library, and to hear it claims that if anything users turned off by horrendous messages are simply being lazy by not just sucking them up for the good of the cause. Cheers, Greg (*) And let me be clear that by "problem" here I really do mean "less than ideal circumstance" rather than "flaw", because in many cases these libraries are very elegantly designed codes which are probably close to the optimal solution given the limits imposed by the C++ language.

5 8

[BGL] reverse_graph
by Fabien Castan 11 Dec '11

11 Dec '11

Hi, I have some troubles using boost::transpose_graph since boost 1.48. See the sample code. Fabien #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/copy.hpp> #include <boost/graph/transpose_graph.hpp> template<class GraphIn, class GraphOut> class Copier { public: Copier( const GraphIn& gIn, GraphOut& gOut ) : _gIn(gIn) , _gOut(gOut) {} template<class VIn, class VOut> void operator()(const VIn& vIn, VOut& vOut) { _gOut[vOut] = _gIn[vIn]; } private: const GraphIn& _gIn; GraphOut& _gOut; }; struct CustomVertex { }; struct CustomEdge { }; typedef boost::adjacency_list< boost::setS, // disallow parallel edges (OutEdgeList) boost::vecS, // vertex container (VertexList) boost::bidirectionalS, // directed graph CustomVertex, CustomEdge, boost::no_property, // no GraphProperty boost::listS // EdgeList > GraphContainer; int main( int argc, char** argv ) { const GraphContainer a; GraphContainer b; Copier< GraphContainer, GraphContainer > copier( a, b ); // still works as before boost::copy_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); // works with boost 1.47, but doesn't compile with boost 1.48 boost::transpose_graph( a, b, boost::vertex_copy(copier).edge_copy(copier) ); //<<<<< }

2 4

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

11 Dec '11

I was asked this question regarding DE: >... The Boost Graph Library (BGL) >is often used for graph optimization purposes, and the geometry stuff >is used to do things like lay out integrated circuits with lots of >costs and constraints. There are the math and statistical functions. >Are these and other Boost libraries complementary or orthogonal to >your library? > I'm not familiar with BGL, but from its documentation, DE and BGL seem to be rather orthogonal. As for the math and statistical functions, I believe DE could complement these as yet another mathematical tool. Adrian Michel

1 0

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 11 Dec '11

11 Dec '11

Hi Beman On 12/11/2011 6:31 PM, Beman Dawes wrote: > >> Would there be interest in a C++ Differential Evolution optimization (DE) >> library as part of boost? > > Seems interesting, and you've clearly put in a lot of work, and the > documentation makes a good initial impressions. But see below... > Thanks! >> The full documentation is at http://www.amichel.com/de/doc/html but I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . > > After skim reading the overview and the beginning of the tutorial, I > was left with several unanswered questions: > > * What are some practical scientific or engineering problems that DE > is good for? I personally got interested in DE while doing some research in the area of algorithmic trading system optimization. But DE is generic - it can be used to optimize any function that would otherwise be very hard or impossible to optimize using more traditional methods. DE is used in many areas, some of which are listed here: http://www.icsi.berkeley.edu/~storn/code.html#appl and here: http://www.icsi.berkeley.edu/~storn/code.html#comm or to summarize: chemistry, electronics, physics, agriculture, telecommunications etc. > I'm having trouble calibrating - is your library > primarily aimed at research and academic problems or is it an everyday > tool for use in a broad spectrum of organizations? > I believe the answer is "both". > * Who is the library aimed at? Is the library most likely to be used > by optimization specialists who already know about DE or is it > something that can be used by a wide range of programmers? > I tried to design the library so that it can be easily used "out of the box" by all programmers, who can choose any of the predefined policy classes for default behavior. The de_test application illustrates this usage mode: the user can implement a de::objective_function derived class with their own function to optimize, and then build and run the application to get the best output. However, those interested in tweaking its behavior, can create their own policy classes and override the defaults. One of the obvious advantage of a standardized DE library is that these customized components could then be shared with the community at large. BTW, DE has the added benefit of not having been patented by its authors, for the very purpose of making it widely available. Thanks, Adrian Michel

1 0

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

11 Dec '11

Hi Oliver, On 12/11/2011 9:52 PM, Oliver Kullmann wrote: > > >> I took a peak at the overview and some of the other pages and from >> what I can see initially, it looks like a very useful library for >> artificial intelligence. I have very limited knowledge in the field >> but this is something that grabs my interest, so if it's made public >> I'll definitely use it for future projects that would benefit from >> it. Of course whether it is suitable for Boost is for others to >> determine. >> >> Philip Bennefall >> > > It seems to me that the application domain is not "artificial intelligence", > but arbitrary optimisation problems. > In general, I would like to see more algorithms in Boost. > This library seems a good example, judging from its applicability: > it seems to be widely applicable. > > Oliver > Yes, you are correct, DE is generic, doesn't know or care what the nature of the objective function is. Thanks, Adrian

1 0

Re: [boost] Boost.Thread and Boost.Move collision
by onlyone＠senet.com.au 11 Dec '11

11 Dec '11

>Vicente J. Botet Escriba: >> Le 01/12/11 18:11, onlyone(a)senet.com.au a ?crit : >>>>> 1) Move Boost.Move elements to boost::move:: namespace >>>>> 2) Move Boost.Thread elements to boost::thread namespace >>>>> 3) Modify Boost.Thread to make use of Boost.Move >>>>> >>>> FWIW, I think 3) is what sounds obvious to me. Now maybe there's >>>> reasons to >>>> avoid coupling those libraries together but I'm not sure what they >>>> would be. >>>> >>>> Philippe >>> Hi, >>> I have been working on a patch to do just that. I have not run into >>> any major issues so far. Modifying Boost.Thread to use >>> Boost.Move solves two problems: >>> >>> 1) It fixes the name collision (obviously). >>> 2) It allows types that have been designed to use the Boost.Move >>> emulation to interoperate with Boost.Thread. (This is relevant >>> for futures/promises.) >>> >> Could you post the patch or attach it to a Trac ticket? >> >Any news of this patch? > I have been working on it. I was able to implement the basic functionality in a matter of hours (Boost.Move is very easy to use). Unfortunately, I have been having trouble "Boostifying" the code, as I am unfamiliar with the reasons for many of the workarounds in the existing code (I am worried about causing regressions in these). I have not yet started on the documentation or tests. This patch is still my #1 priority, so expect it soon! Regards, Evan Wallace

2 1

update from 1_44 to 1_48: build questions
by Oliver Kullmann 11 Dec '11

11 Dec '11

Hello, we want to update from 1_44_0 to 1_48_0. Our old build-process is as follows (for Linux): 1. cd tools/jam/src 2. CC="$(gcc_call)" CFLAGS="-fno-strict-aliasing" ./build.sh cc 3. cp bin.*/bjam $(boost_base_build_dir) 4. cd ../../.. 5. echo "using gcc : $(gcc_version) : $(gcc_call) : ;" > $(boost_base_build_dir)/bjam_config 6. $(boost_base_build_dir)/bjam --user-config=$(boost_base_build_dir)/bjam_config --prefix=$(boost_installation_dir) --build-dir=$(boost_build_dir) install --without-python --without-wave --without-mpi -sBZIP2_INCLUDE=$(bzip2_source_library) -sBZIP2_LIBPATH=$(bzip2_link_library) It seems that "b2" is (just) bjam? However it is not really clear from the documentation how to build (and use) bjam (apparently via boostrap?)? And then apparently some of the above parameters of bjam, for example prefix, are now parameters of bootstrap? We would be glad if somebody could tell us (or some link) how to update the above process. Thanks in any case for your consideration. Oliver

2 2

[chrono] i/o to locale or not to locale
by Vicente J. Botet Escriba 10 Dec '11

10 Dec '11

Hi all, currently Chrono provides a limited localization interface for duration and time_point I/O that is not satisfactory. The current implementation Boost.Chrono V1.2 (Boost 1.48) is based on the alternative A1 (see below) in which the hour,minute,second and the epoch can be localized. This could give the impression that chrono i/o is localized, but as Aryton as signaled it is not enough. I'm working on redesigning the chrono i/o in order to make a proposal with Howard Hinnant to the C++ committee. Two main alternatives A1- follow the formatting of recognized international body as ISO. A2- Add localization of specific units and epoch to the preceding format. It seems that the localized alternative seems to have less chances to be adopted, as no other library in the standard is providing these kind of facilities, and locale message facility is not completely satisfying. Things could change if we had a concrete proposal for improving the standard locale library (in which Aryton seems to be working IUC). More detail on the two alternatives: A1- Provide formatted i/o following the ISO 80000 http://en.wikipedia.org/wiki/ISO/IEC_80000, http://en.wikipedia.org/wiki/ISO_31-1, The format for duration could be <value> <unit> With unit been day, hour, minute, second, decisecond, centisecond, ..., decasecond, hectosecond, ... Note that the unit is always in singular form and in English. Next follows several valid inputs for duration 3 day 9 hour 1 second 0 second -1 second 3.77 millisecond 34 [1/30]second time_points could be formatted as <duration> <since epoch> where <since epoch> is a string that identifies the starting point of the epoch's clock, e.g. since boot, since process startup, .... The string associated to each clock are fixed and configurable specializing the trait clock_string Next follows several valid inputs for time_point. 123456 second since boot A1.a We can also consider ISO 8601. IMO, an acceptable format for durations could be a variation of the extended format independently of the date. <hours>:<minutes>:<seconds>[.fractional_seconds] Note that <hours> here is not limited to 24, and gives the total number of hours. A1.b An additional alternative could be to represent a duration as following a variant of the period representation: P[n]Y[n]M[n]DT[n]H[n]M[n]S in which the year and month are represented by days. E.g. P[n]DT[n]H[n]M[n]S[n]F P1234DT12H30M5S555F A2 - Make durations and time point i/o locale dependent. Based on the previous alternative, add the possibility to add specific locale facets that could format a duration following the pattern <value> <unit> <unit> <value> <hours><:><minutes><:><seconds>[<.>fractional_seconds] Here <value> and <unit> will be formatted following the specific locale and in this case the unit could have specific plural forms. For example in French the user could specialize the facets so that she could get 1 jour 3 jours 9 heures 1 seconde 0 secondes -1 seconde 3.77 milliseconds 34 [1/30] de seconde and in Spanish 1 segundo 0 segundo -1 segundo Add the possibility to add specific locale facets that could format a time_point following the pattern <duration> <epoch> <epoch> <duration> system_clock::time_point is a special case that should be formatted as a localized date, relative to the epoch 1900/01/01. A3 - Add on top of A2 some _byname facets. The fist alternative is in line with the money standard locale category that uses standard symbols, as $ or USD. It has the drawback that the <value> could be localized while the <unit> is not, e.g. 1,234 second Note the use of ','. The third alternative is IMO closer to the user expectations, but needs a better locale messages/by_name facet. The second alternative is a pragmatic one that left the possibility to build A3 when a satisfying messages/by_name facet is available. Boost.Chrono 2.0 in the trunk is a prototype of A2, that doesn't provides facets by locale name, only a default English implementation. That means that for the time been, the user needs to imbue a locale with her specific facet to get the expected localization (See french.cpp example in the SVN repository) What the Boost community think about this? Towards which alternative should Boost.Chrono move? Should Boost.Chrono wait until a concrete standard proposal is accepted? Thanks in advance, Vicente

2 6

Re: [boost] Boost.Thread and Boost.Move collision
by onlyone＠senet.com.au 10 Dec '11

10 Dec '11

>> >> 1) Move Boost.Move elements to boost::move:: namespace >> 2) Move Boost.Thread elements to boost::thread namespace >> 3) Modify Boost.Thread to make use of Boost.Move >> > >FWIW, I think 3) is what sounds obvious to me. Now maybe there's reasons to >avoid coupling those libraries together but I'm not sure what they would be. > >Philippe Hi, I have been working on a patch to do just that. I have not run into any major issues so far. Modifying Boost.Thread to use Boost.Move solves two problems: 1) It fixes the name collision (obviously). 2) It allows types that have been designed to use the Boost.Move emulation to interoperate with Boost.Thread. (This is relevant for futures/promises.) Evan Wallace

2 2