- Boost - lists.boost.org

GSoC project " Enhanced vector and deque containers "
by ahmad samir 08 Mar '15

08 Mar '15

Good morning guys I'm Ahmad, I want to contribute in " Enhanced vector and deque containers ", I'm working on the programming competency test, but I have a question about the main idea * The idea is " Write full-fledged and enhanced C++11 versions of std::deque and std::vector with extra functionality that gives the programmer more control over buffers, segments and iteration " . * Is there specific features or new functionality you want to add or I should search for some new features in other languages like " java & python " which isn't in C++ vector and deque containers, or search for what can give the programmer more control on these containers ?.

1 0

GSoC 2015 Paritipation
by vladiksonic＠mail.ru 07 Mar '15

07 Mar '15

Dear Boost, I am eager to participate in GSoC 2015 in one of the two projects (from this page: https://svn.boost.org/trac/boost/wiki/SoC2015 , 1 or 5). As far as I understood - the first one is tougher, and (as for me) conditions are clearer, and the second one is (seemingly) simpler. I am totally new to Boost (never used it, actually, but that is because I mostly used C++ in programming contests). I am familiar with algorithms (from contests), and testing (manual, both for stability and performance), but I am not very familiar with C++11 (but I can compensate for that, because I have knowledge of other languages (C#, Javascript (nodejs)) and older C++ versions), and automated tests. At first, I'd like to ask - what should I choose? My main goals are: 1) To enter the community 2) Learn C++11 new features (I will start early on that, obviously) 3) And to learn how to code open-source programs (up till now I only have closed-source ones, apart from one project, which has not-so-good code quality - see here: https://github.com/hotab/OpticalBuilder ) 4) Plus understand better how to maintain library code (I already have some understanding of that, but I want to sharpen it). Both can give me that. I'm looking forward to hearing from you, Vladislav Babkin

1 0

[dynamic_bitset] Maintainer available?
by Riccardo Marcangelo 07 Mar '15

07 Mar '15

Hi Boost developers, Does anybody know if the maintainer of dynamic_bitset is available? I made some contributions to dynamic_bitset on GitHub last year but there doesn't appear to have been any activity in the repository for many months. My pop_back() commit was accepted into the 'develop' branch over 5 months ago and, despite passing tests, has yet to be merged to 'master'. I also implemented capacity(), reserve(), and shrink_to_fit() which have been sitting in a pull request waiting to go into 'develop' since November. It would be nice to get these into 1.58.0 if possible. Kind regards, Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-Maintainer-available-tp46… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

GSoC project " Enhanced vector and deque containers "
by ahmad samir 07 Mar '15

07 Mar '15

Good morning guys I'm Ahmad, I want to contribute in " Enhanced vector and deque containers ", I'm working on the programming competency test, but I have a question about the main idea * The idea is " Write full-fledged and enhanced C++11 versions of std::deque and std::vector with extra functionality that gives the programmer more control over buffers, segments and iteration " . * Is there specific features or new functionality you want to add or I should search for some new features in other languages like " java & python " which isn't in C++ vector and deque containers, or search for what can give the programmer more control on these containers ?.

1 0

[GSOC2015] uBLAS Matrix Solver Project
by Rajaditya Mukherjee 07 Mar '15

07 Mar '15

Hi, My name is Raj and I am Phd student in Computer Graphics. I am interested in tackling the problem of uBLAS Matrix Solver and in order to write my proposal, I am looking for inputs for which of the following algorithms will be most useful for prospective users in boost-numeric library. Here is a categorical list of all the prospective ones which will bring uBLAS updated to other commercial libraries like Eigen/Armadillo. Please let me know your preferences.... *David Bellot* : As a potential mentor, do you have any specific additions or deletions for this list? This could also be useful for other candidates pursuing this project. *DENSE SOLVERS AND DECOMPOSITION* : 1) *QR Decomposition* - *(Must have)* For orthogonalization of column spaces and solutions to linear systems. (Bonus : Also rank revealing..) 2) *Cholesky Decomposition* - *(Must have)* For symmetric Positive Definite systems often encountered in PDE for FEM Systems... 3) *Householder Method* - Conversion to tridiagonal form for eigen solvers. *SPARSE SOLVERS AND PRECONDITIONERS* : 1) *Conjugate Gradient* - *(Must have)* For symmetric Positive Definite systems, this is the kryvlov space method of choice. Both general and preconditioned variants need to be implemented for convergence issues. 2) *BiCGSTAB* *(Needs introspection)* - For non symmetric systems.. 3) *Incomplete Cholesky Decomposition* *(Good to have)* - For symmetric Positive definite sparse matrices, to be used as preconditioner as extension to (1) for preconditioned CG Methods ... 4) *Jacobi Preconditioner* *(Must have)* - As prerequisite for step(1). *EIGEN DECOMPOSITION MODULES (ONLY FOR DENSE MODULES)**:* 1) *Symmetric Eigen Values* - *(Must have)* Like SSYEV Module in Lapack - That is first reduction to a tridiagonal form using Householder then using QR Algorithm for Eigen Value computation. 2) *NonSymmetric Eigen Values* - *(Good to have)* Like SGEEV module in Lapack - using Schur decompositions as an intermediate step in the above algorithm. 3) *Generalized Eigen Values* - *(needs introspection)* I use this in my research a lot and its a good thing to have.. ** Computing Eigen Decomposition of sparse modules needs special robust numerical treatment using implicitly restarted arnoldi iterations and may be treated as optional extensions.

3 3

[MPL lite or MPL 2] A modest proposal
by Robert Ramey 07 Mar '15

07 Mar '15

I've been looking at another thread which address the problems of maintaining and/or finding a maintainer for MPL. I've come up with an idea for a proposal which I've laid out here: Library Idea MPL lite or MPL2 <http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/> -- View this message in context: http://boost.2283326.n4.nabble.com/MPL-lite-or-MPL-2-A-modest-proposal-tp46… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 18

[asio] Massive regression failures
by Aparna Kumta 06 Mar '15

06 Mar '15

I am running the regression tests on the develop branch with Oracle Solaris Studio12.4 on Solaris 11.2 OS. Tests for asio fail as follows: ../boost/system/config.hpp", line 34: Error: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK. I looked at the developer issues on http://www.boost.org/development/tests/develop/developer/issues.html and see that asio tests fail similarly. I'm not sure what causes both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK. to be defined on the command line. Any idea on how this can be fixed? Thanks, Aparna

2 2

[move] unique_ptr: problems with move-assign constructor when used with base/derived classes in C++03
by Adam Romanek 06 Mar '15

06 Mar '15

Hi, There is a problem with move-assignment constructor in boost::movelib::unique_ptr when used with a pair of base/derived classes in C++98/03 mode [1] (uncomment the code to see the compiler error). Is it a known issue? Or a limitation of the emulation? I discovered the issue when I wanted to use boost::movelib::make_shared in an answer to a question on StackOverflow [2], i.e. return boost::movelib::make_shared<Derived>(); Where the return value is boost::movelib::unique_ptr<Base>, but unfortunately because of this issue, in C++03 we need to use: return unique_ptr<Base> x(new Derived()); I can create a ticket if that is desired. Nevertheles, thanks for boost::movelib::unique_ptr anyway! BTW, note how the appearance of boost::movelib::unique_ptr makes the most voted answer on the question [3] invalid. This is where my answer comes in. Best regards, Adam Romanek [1] http://melpon.org/wandbox/permlink/8Rvk2g7LJ0Ey0BQL [2] http://stackoverflow.com/a/28193068/1776942 [3] http://stackoverflow.com/q/2953530/1776942

2 2

GSoC 2015 project " Enhanced vector and deque containers "
by ahmad samir 06 Mar '15

06 Mar '15

Good morning I wish to contribute in this project, now I am working on programming competency test. I want to ask about Is there specific or preferable method to show you my work or just upload my code in any online compiler or Github?.

1 0

[random] Quantization effects in generating floating point values
by John Maddock 05 Mar '15

05 Mar '15

First off, I notice there are no examples for generating floating point values in Boost.Random, so maybe what follows is based on a misunderstanding, or maybe not... Lets say I generate values in [0,1] like so: boost::random::mt19937 engine; boost::random::uniform_01<boost::random::mt19937, FPT> d(engine); FPT d = d(); //etc Where FPT is some floating point type. Now my concern is that we're taking a 32-bit random integer and "stretching" it to a floating point type with rather more bits (53 for a double, maybe 113 for a long double, even more in the multi-precision world). So quantization effects will mean that there are many values which can never be generated. It's true that I could use independent_bits_engine to gang together multiple random values and then pass that to uniform_01, however that supposes we have an unsigned integer type available with enough bits. cpp_int from boost.multiprecision would do it, and this does work, but the conversions involved aren't particularly cheap. It occurs to me that an equivalent to independent_bit_engine but for floating point types could be much more efficient - especially in the binary floating point case. So I guess my questions are: Am I worrying unnecessarily? and What is best practice in this area anyway? Thanks, John.

4 12