March 2011 - Boost - lists.boost.org

[dynamic_bitset] tickets triaging
by Alexey Stukalov 27 Mar '11

27 Mar '11

Dear boost developers, there's a number of untriaged issues related to dynamic_bitset component in boost trac. In particular, there are 2 patches by me addressing the performance of find_first()/find_next(): https://svn.boost.org/trac/boost/ticket/5158 https://svn.boost.org/trac/boost/ticket/5159 Is there a possibility they would be reviewed? Thanks, Alexey

1 0

GUI objects for boost
by farah inamdar 26 Mar '11

26 Mar '11

hi; I would like to discuss my project idea with the boost developer mailing list and mentors. I wold like to work with the UI for box , btn , frame etc etc and this is the way I am going to do it. What ever road map you set for the project idea. -- Warm Regards, Farahnaj......... :-)

2 1

Boost.Polygon edge, polyline and edge set concepts
by farah inamdar 26 Mar '11

26 Mar '11

I am studying in Mtech cs. In my graduation i built software in java which has have most of functions like PowerPoint. So i am confident that i can handle this polygon edge related problem. just give me some guide lines. My Id is farahinamdar(a)gmail.com -- Warm Regards, Farahnaj......... :-)

2 1

[GSOC]Asking for advice
by Faiçal 26 Mar '11

26 Mar '11

I want to participate (for the first time) in GSoC, particularly boost's projects. I first choosed to apply for the "Checks & Hashes" project but I discussed briefly on #boost irc and people here convinced me to take a look on the SIMD Library project. This project seems very challenging, I'll try it despite my poor experience. I start reading about SIMD, I'm currently reading it's wikipedia article and some articles found by google and I download the AltiVec programming interface manual. It would be useful for me if some of you guys give me links for good references articles or documentation about this technology. This post is essentially for introducing myself to your community and asking advice in preparing my application for the project. Thanks.

2 2

Intel compilation
by barend 26 Mar '11

26 Mar '11

Hi, The Boost.Trunk summary now gives for some Intel compilers, since some time: Test output: Sandia-intel-10.1 - geometry - distance / intel-darwin-10.1Rev 70458 / Wed, 23 Mar 2011 01:41:17 +0000 Report Time: Thu, 24 Mar 2011 07:47:34 +0000 Compile [2011-03-23 04:42:50 UTC]: fail "/opt/intel/cce/10.1.024/bin/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -D__WINT_TYPE__=int -I".." -I"../boost/geometry/extensions/contrib/ttmath" -I"../libs/geometry/test" -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/geometry/test/algorithms/distance.test/intel-darwin-10.1/debug/distance.o" "../libs/geometry/test/algorithms/distance.cpp" ../boost/detail/fenv.hpp(11): catastrophic error: #error directive: This platform does not have a floating point environment #error This platform does not have a floating point environment ^ compilation aborted for ../libs/geometry/test/algorithms/distance.cpp (code 4) Meaning the boolean variable BOOST_NO_FENV_H is not set. Is that compiler-detection broken somehow? It is not on all Intel compilers. Regards, Barend

3 6

Compilation for PGI and ublas
by Barend Gehrels 26 Mar '11

26 Mar '11

hi, The Boost.Trunk regression report gives me for most of the tests, on Sandia-pgi-11.2: catastrophic error: #error directive: Your compiler and/or configuration is unsupported by this verions of uBLAS. Define BOOST_UBLAS_UNSUPPORTED_COMPILER=0 to override this message. Boost 1.32.0 includes uBLAS with support for many older compilers. This message is also reported for all tests in numeric/ublas. We're only slightly dependant on ublas (only in matrix transformations). They are indirectly included in many testfiles but are not really used there. Will I set BOOST_UBLAS_UNSUPPORTED_COMPILER to 0, for the tests? I checked and didn't notice any other library doing that. Regards, Barend

1 0

[Review] XInt Review
by Joel Falcou 26 Mar '11

26 Mar '11

Here is my review for XInt. Currently I think the library should not be included in boost as a lot of problems are, in my opinion, still to be fixed and the design has to be rethought. *********************************************************************** * What is your evaluation of the design? Large integer is a bit like XML and Unicode. Lots of people want to do such a library because it has a high impact of usefulness and, from afar, it doesn't sounds *this* complicated. Alas, it is :/ The premises are OK. We have some large integer type that has proper value semantic and can be used in a variety of operations and functions. So far, so good. The main culprit is that the current library design is rather hardwired to work with a choice of implementation the author thought to be OK at some point but which still have to be proven better than existing solution. The overall design lacks separation between the data and the algorithm that makes the library difficult to extend: what if i want to take an arbitrary range of integers and look at them as a huge series of bits ? What if i don't want the extra memory overhead so i can mmap some files directly into memory (cause reading a 10k bits integer is a no-no) ? Can I pass the integer type to a STD algorithm if I want to iterate over the bytes it contains ? or copy them using boost::range copy ? On the data side, i think being forced to use a given representation is wrong. The Ideal should be that the library provide a fall back implementation but provide adaptor to adapt any kind of data to be looked at as a large integer. The definition of a LargeInteger concept would help defining such an adapting interface and make the library more fluid. For example, what if i want to implement LCM ? * What is your evaluation of the implementation? The implementation is poor for various reasons: - author uses COW for performance reasons. Alas COW has been demonstrated again and again to be of little interest. Looking at the problem 10s (types holding arbitrary large amount of data to be chained in operations without copy) should have lead to an expression template based solution. Capture a whole chain of operations on values, compute the worst case nbr of bits to store, allocate once then compute inside. It prevent spurious allocation and make the algorithms easier to write. Additionally, ET would help detecting expression pattern for which a non naive algorithm could be applied. - virtual inheritance: looking at integer_t shows: class integer_t: virtual public .... Why ? It seems you're trying to implement some policy based design but i cant see why virtual inheritance is used ? Do you get problem not having multiple definition in your mixins ? - There is a lot of unwarranted pass-by-value function prototype which seriously impact performance even with COW. pass-by-ref > pass-by-value + COW. Moreover, the "thread safety" COW is dubious. - the headers are obscenely big. It could be easier to follow the code it there was not this 2k+ line mammoth files. * What is your evaluation of the documentation? The documentation is OK but it is rather hard to navigate as there is real links between sections, forcing me to go back and forth between sections. * What is your evaluation of the potential usefulness of the library? The problem the library tries to solve is a very important one as shown by the large amount of similar project. Having such a library is worthy of inclusion in boost but not in the present form and shape. * Did you try to use the library? With what compiler? Did you have any problems? I tried some examples from the doc on gcc 4.5 with no real problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? I've been doing research and development on scientific computing for 9 years. If the specific problem of large integer is a bit of a fringe domain for me, I have been collaborating on such design in some projects. * Do you think the library should be accepted as a Boost library? No. In its current form, the library *should not* be accepted into Boost. performances claims are not backed up (and other reviewers show it can be far better0 the design lacks of genericity and its implementation is , in my opinion, sub-optimal. To be accepted the following point should be addressed: - use expression template to handle efficient combination of operations and potentially detect optimisable pattern. Proto is a shoe-in for this. - the library entities should be made more generic by providing an extended integer adaptor facility that make one able to substitute a custom integer representation (like having extended_integer<GMP>) for corner case stuff. This adaptor will provide an interface able to turn these types into a type fulfilling the underlying Large Integer concept the library need to handle. Being compatible with GMP should even be a goal and a selling point for the library. - do real benchmarks and compare to existing state of the art solution, at least show benchmarks against GMP on realistic use cases. - the algorithm should be more generic and not be tied to the concrete type of large integer used. Frankly, licensing issues aside, a proto based library able to wrap GMP if needed and with Range based interface could already cover 80% of needs and provides correct speed. Then building on top of that to add new algorithm and new back end representation and adaptors would fill the library in a very smooth way.

13 34

failed to auto link
by Tal Agmon 26 Mar '11

26 Mar '11

It seems to be an issue with auto link when BOOST_VERSION ends with 0 (in example 1.47.0) windows fails to auto link since generate libs truncates '0'. May I suggest adding 'x' at the end (1.47.0x) Tal Agmon -- Sent from my mobile device

3 4

hash_combine vs hash_value
by Michael Goldshteyn 26 Mar '11

26 Mar '11

After reading the explanation of how hash_combine should be used, I am left wondering. Why is the recommendation for hash_combine different from what one would intuitively expect? Namely, given: struct MyStruct { int a; int b; int c; }; The recommendation via examples and documentation is: size_t hash(const MyStruct &s) { size_t hashValue=0; // Combine hashes of all elements hash_combine(hashValue,s.a); hash_combine(hashValue,s.b); hash_combine(hashValue,s.c); return hashValue; } Rather than what I would think is the expected correct approach: size_t hash(const MyStruct &s) { // For a composite hash, start by hashing the first element size_t hashValue=hash_value(s.a); // Then, combine with hashes of the remaining elements hash_combine(hashValue,s.b); hash_combine(hashValue,s.c); return hashValue; } Thanks, Michael Goldshteyn

5 8

[thread] Boost 1.46 and 1.46.1 fails on SunStudio/OpenSolaris
by Artyom 26 Mar '11

26 Mar '11

Hello, I've got failures when tried to use Boost.Thread on OpenSolaris with SunStudio, I hadn't got such problems with older versions The error is: "./boost/thread/future.hpp", line 422: Error: boost::unique_lock<boost::mutex>::operator=(boost::unique_lock<boost::mutex>&) is not accessible from boost::detail::future_waiter::all_futures_lock::all_futures_lock(std::vector<boost::detail::future_waiter::registered_waiter>&). It wasn't a problem in older versions of Boost. At least 1.41 worked fine for me. The patch that fixes this issue is attached. Artyom

1 0