- Boost - lists.boost.org

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

[inspect] exceptions (FW: [Boost-users] no exceptions)
by Robert Kawulak 26 Mar '11

26 Mar '11

>From Boost Users ML: > From: Hochhaus, Andrew > I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ > -fno-exceptions flag. However, it appears that some spots in boost > library code: > > a) throw exceptions with the "raw" throw keyword [instead of > BOOST_THROW_EXCEPTION or boost::throw_exception] > b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too? Best regards, Robert

11 48

[xint] quick review
by Domagoj Saric 25 Mar '11

25 Mar '11

Apologies for lack of proper review structure, I'm working with last bits of free time to post before the deadline... IMO, the proposed XInt, as can be downloaded from the vault, should NOT be accepted into Boost. Rationale: The reasons were mostly already covered by other boost.devel posters and pretty much all fall into the categories of a too coupled/inflexible and inefficient design. My primary concern is lack of support for true, efficient, no-fail-guarantee fixed-size integers: the provided fixed-size support still uses dynamic memory allocation (which can fail and requires/introduces EH code) and the nothrow policy does not in fact disable the use of exceptions (it only wraps and 'eats' them with try-catch blocks...which is just plain inefficient...this is like implementing malloc in terms of new instead of the other way around). For such low level operations, as fixed-sized integer arithmetic, it is quite reasonable to expect the implementation to be able to work even without linking to the CRT (i.e. no use of keywords new, virtual or throw)... This might at first be viewed as a possibly 'conditional yes' vote but since Chad has repeatedly said that he considers fixed-sized integers to be 'second class citizens' of his library I vote no for such a library... I am also not convinced by the rationale behind the different-than-built-in-behaviour (sign-magnitude, overflow NaN...). >"Chad Nelson" <chad.thecomfychair(a)gmail.com> wrote in message >news:20110302202855.5cd8067f@ubuntu... > >>On Wed, 02 Mar 2011 18:18:33 +0100 >>Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: >> >> [...] Also, it seems that the object always contains the copy count >> and a readonly boolean, which total 2 words, even if COW is disabled. > >Eliminating sixteen bits of overhead, on an integer that is almost >always going to be larger than 64 bits (and often *much* larger), seems >to be a premature optimization at best. 2 words are 64 bits on a 32 bit system and 128 bits on a 64 bit system...that's 25% of a 512 bit number. In fact, for a fixed-sized integer with disabled COW, there are, AFAICT, two redundant std:size_ts and two bools (in addition to the data pointer and dynamic memory allocation) per integer...that certainly is not so easily dismissible, especially on a 64 bit system and especially if we also consider the code that maintains those 'useless' data members...Quite to the contrary, I would sooner accuse your approach of premature pessimization (have you even examined the assembly output of your code?). In one post you complained that you are already tired of all the criticism on this list but please try to learn from this. The above misunderstanding and/or unwarranted dismissal of data layout/storage issues along with things like thinking that virtual inheritance is resolved at compile time, not knowing about the CRTP and misunderstanding of when to 'pass by value for performance' shows that you have holes in your knowledge which should make you more humble before honest criticism... You also complained about not getting enough feedback in the last iteration of your library, IMHO your attitude (of fixing your library on your own set of use cases) again may have something to do with that. I remember way back then people were already criticising the hardwired dynamic allocation and data-layout&storage coupling design. I proposed that you extract algorithms into free functions that simply take and work on data ranges as this would both eliminate template bloat (in your current design the algorithms get replicated for every integer_t instantiation) and allow for cleaner implementation of different data storage strategies. As far as I remember you gave little heed to these concerns/suggestions or complained that that would be too much time consuming to implement while OTOH you spent who knows how much time on implementing COW which AFAICT turned to be a misguided premature optimization (of an a priori inefficient design)... When I finally saw that you actually defended your hardwired dyn.mem. allocation by saying that it enables faster swaps I simply gave up on replying at that time deciding I'd wait for an official review (when boost.devel input has to be taken into consideration else you don't get accepted)... ps. I'm sorry if some/all of the above mentioned issues were already resolved (I did not manage to read through the whole discussion before the review deadline)... pps. I saw FFT being mentioned, you migh want to check out this http://drdobbs.com/cpp/199500857 ppps. You use a member-function-pointer based "unspecified bool type" implementation which produces suboptimal code on MSVC <10...IMO a plain operator bool would probably do just fine here as the built-in integral types also implicitly convert to bool... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

12 29

Unable to build boost python library in 1.46.1
by Richard Hadsell 25 Mar '11

25 Mar '11

I am trying to build the Boost 1.46.1 libraries on a Fedora 7 Linux system with the default g++ 4.1.2 and Python 2.5. The compilations do not find the python headers, producing a zillion error messages starting with one like this: In file included from ./boost/python/detail/prefix.hpp:13, from ./boost/python/converter/registrations.hpp:8, from libs/python/src/object/function_doc_signature.cpp:9: ./boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory The reported compilation command looks like this: "/usr/bin/g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -fno-strict-aliasing -fno-tree-ccp -march=opteron -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-4.1.2/release/address-model-64/instruction-set-opteron/threading-multi/object/function_doc_signature.o" "libs/python/src/object/function_doc_signature.cpp" I tried to follow the latest Getting Started instructions, which changed a bit from the last version I built (1.44.0) to build bjam: cd tools/build/v2 bootstrap.sh bjam install --prefix=../../.. cd ../../.. bin/bjam --user-config=user-config.LINUX_AMDF7 threading=multi instruction-set=opteron address-model=64 variant=release link=static,shared --stagedir=stageF7 stage My user-config.LINUX_AMDF7 file contains this: using gcc : 4.1.2 : /usr/bin/g++ : <compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" <linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; using python : 2.5 : /usr ; Can someone explain why the compilations are not getting the correct include path for Python (/usr/include/python2.5/)? BTW, the Getting Started page http://www.boost.org/doc/libs/1_46_1/more/getting_started/unix-variants.html in section 5.2.1 step 2 tells me to "Run bootstrap.bat". -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

4 8

Re: [boost] A possible GSOC 2011 proposal idea
by Chad Seibert 25 Mar '11

25 Mar '11

Hi, First of all, many thanks for the feedback! Much of the discussion has been in whether it is possible for me to accomplish such a task over the summer. The answer is no; a library designed to meet Boost's standards will not be done over the summer. However, a substantial amount of the work will be done over the summer and it will continue over the next year until it is satisfactory. I will then be responsible for maintaining it for as long as required. In order for you to understand the scope of this project, it must be made clear that the project references itself many times. For example, MILP's and ILP's are solved using the exact same algorithms, so for all intents and purposes, they are the same. Second of all, solving ILP's using branch and bound or cutting planes both require a strong algorithm for solving their relaxed forms, i.e. their LP relaxations. Third, the bulk of the effort in solving LP's using the refined simplex algorithm is in solving a system of linear equations. This is by far the most difficult part of the entire project and is what I intend to spend the summer doing. It will be difficult for the aforementioned reasons; hence the topic of my GSOC proposal will be efficiently solving linear systems (LS). After GSOC, I will continue my work and write LP and ILP solvers. As for the scope of solving LS, there are many different algorithms designed to do just that. In order to limit the scope, I will not consider parallel algorithms or distributed algorithms. If the Boost community thinks that these are reasonable and I should forgo solving LP in favor of solving large (> 100,000x100,000) LS, we can certainly discuss this. The following algorithms are up for consideration: * LU decomposition for small matrices * Iterative methods for large matrices, such as conjugate gradient for positive definite matrices Of course, this will all be integrated into the already existing uBLAS library. There are many issues with getting such solver to work well in practice, namely reducing fill-in, numerical stability, and performance. In any case, getting a general purpose LS solver is the first step towards getting an LP solver running. Therefore, it is the focus of my work this summer and only afterwards will I work on LP-related algorithms. One last this is that it wasn't my intent for my pre-GSOC submission to be anywhere the quality required for Boost submission. It was only there to show my support towards this project and that I'm committed fully to its success. Thanks again for your feedback! Chad

7 15

[xint] Some preliminary review notes
by Vladimir Prus 25 Mar '11

25 Mar '11

Folks, I've promised to post initial summary of Boost.Xint this Monday, but real life has interferred. I apologise. I've made a pass over review emails, and it seems that a few high-level points were raised: - Whether COW is good idea or not, and whether current COW is truly thread-safe. - Whether ET should be used - Whether data copy in "a + b + c" should be eliminated - Whether the library is "fast", in particular: - Do algorithms have best big-O complexity? - Are fixed-size integers fast enough - Whether it would be better to separate algorithms and data represetation - Whether it's possible to optimize specific cases (addition of 128-bit integers, ln+gamma, etc), by some template specializations, or other mechanism. I might have missed something, and I'd appreciate if I was set straight. Please note that we're talking about high-level issues. The number of specific comments is already too high for me to even try tracking them all. At the same time, Chad, I'd appreciate some input from you. - Could you express your current world view of those issues. Whether they are real, important, and what plan do you have about them, if any. Note that you are not required by any means to address every raised concern, but some coherent plan of action will be very important both for further development of your library and for review result. - Do you keep track of technical issues raised? Could you share that list? Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

2 1