- Boost - lists.boost.org

[gsoc 2013] chrono::date
by Anurag Kalia 27 Apr '13

27 Apr '13

After going through related docs and general information, I have some questions regarding the chrono::date library. What is the origin of the name 'chrono'? I have assumed till now, it has something to do with chronology, but I am not sure.Why is date a part of 'chrono' at all? As I understand, chrono::date library is supposed to be based on the counts of sunrises. I am in favour of it because it elegantly circumvents the complications of leap seconds which are unnecessary with date-related arithmetic. But if we want it to be compatible with the rest of chrono library, complications arise:If we use a definition in line with principles of chrono (i.e. not using sunrises for a moment), a date really becomes a time-interval defined by the 00:00:00 of that date + a duration of 1 day, if we follow the rules of chrono library. But the length of a day can be changed today due to insertion/deletion of leap seconds to the conventional 24-hour day, if needed. Moreover, this change is arbitrary, since leap seconds are used to keep the time in sync with earth's rotations, which changes without a fixed pattern.The length of month and year similarly are complicated, not only by the length of days in it (see above) but also by the variable number of days. For example January has 31 days, April has 30 days and February has 28 or 29 days depending upon common year or leap year respectively. Due to the latter, length of year also varies between 365 and 366 days.In essence, there is no fixed duration of day, month or year; unlike the rest of chrono library which fundamentally is based on 'duration' class.Now if we revert to our original definition, our library basically becomes a count of sunrises since epoch. Aren't we forming an independent library from chrono then?What does one mean when one says the chrono::date library interoperates with rest of chrono library? This question is an offshoot of previous question. I am confused as to how far can both parts interoperate given the above-mentioned complications. Subtraction of dates yields us theoretically a duration of a number of days. But since actual time duration of a day is ill-defined (see above), we have to return the answer in resolution of seconds, if we use 'duration' at all. I am unable to think of more possibilities of cross-pollination between the two parts. Am I correct in my reasoning? I am genuinely stuck at this clubbing up of unrelated (to me) classes. Even more so because Boost already supplies such a vast number of header files with least number of interdependencies. A smaller self-contained date library seems (to me) more in line with its principles. Thanks,Anurag Kalia.

5 10

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 27 Apr '13

27 Apr '13

> > [1] http://danlincan.3owl.com/gsoc/Proposal.pdf > > > I have some questions: > > * Why the submit function of all the thread pools doesn't returns the same? > * What is the advantage of returning future from submit call? > .... My personal big issue with a Boost.Thread threadpool is why adding one is necessary when forty lines of C++11 code using Boost.ASIO implements you one: /*! \class thread_pool \brief A very simple thread pool based on Boost.ASIO and std::thread */ class thread_pool { class worker { thread_pool *pool; public: explicit worker(thread_pool *p) : pool(p) { } void operator()() { pool->service.run(); } }; friend class worker; std::vector< std::unique_ptr<thread> > workers; boost::asio::io_service service; boost::asio::io_service::work working; public: //! Constructs a thread pool of \em no workers explicit thread_pool(size_t no) : working(service) { workers.reserve(no); for(size_t n=0; n<no; n++) workers.push_back(std::unique_ptr<thread>(new thread(worker(this)))); } ~thread_pool() { service.stop(); for(auto &i : workers) i->join(); } //! Returns the underlying io_service boost::asio::io_service &io_service() { return service; } //! Sends some callable entity to the thread pool for execution template<class F> future<typename std::result_of<F()>::type> enqueue(F f) { typedef typename std::result_of<F()>::type R; // Somewhat annoyingly, io_service.post() needs its parameter to be copy constructible, // and packaged_task is only move constructible, so ... auto task=std::make_shared<boost::packaged_task<R>>(std::move(f)); // NOTE to self later: this ought to go to std::packaged_task<R()> service.post(std::bind([](std::shared_ptr<boost::packaged_task<R>> t) { (*t)(); }, task)); return task->get_future(); } }; ... and you're done. Moreover, this thread pool integrates seamlessly with Boost.ASIO ioservice callback dispatch which is a huge plus. I took that example from some page on the internet, so I don't claim I wrote most of the above. Do bear in mind before you respond that parts of Boost.ASIO are scheduled to enter the standard in TR2, therefore no you won't need Boost.ASIO as a dependency soon. I'm not ruling out the merit of a Boost.Thread threadpool. For me personally though, the hurdle is very significantly raised: you need to strongly prove to me why your proposed thread pool is much superior to a Boost.ASIO based threadpool. Otherwise I will zero score the GSoC proposal, because in the end we need other proposed projects more. By the way, I actually don't object at all if your proposed Boost.Thread threadpool is a thin wrapper of Boost.ASIO. That, actually, is just fine with me, though I'd doubt Google would feel it substantial enough for GSoC funding seeing as it would be finished within a week. Niall

3 3

[operators] v2 test code
by Andrew Ho 26 Apr '13

26 Apr '13

I took a some time re-working the operators header based on previous feedback provided. Hopefully this will allow us to get a rough base worked out and we can work through some of the details. Most of the general idea is the same as v1, but there are a few changes and in general is not backwards-compatible. As far as I know this should be usable and support at least all of the features provided by v1 or something equivalent (see notes). codepad link: http://codepad.org/F2LrIUD2 notes: 1. Rather than using op1/op2, this version uses template specialization to make the distinction between the two. 2. All math operators have commutative and non-commutative versions, as well as left versions. Distinction is made by struct name, i.e. op is non- commutative, op_commutative is commutative, and op_left is the left variation. Note that there isn't any hard checks to prevent op_left<T, T> (which obviously makes no sense, may even result in a compiler error regardless), but the internal composite operators all use template partial specialization which don't have op_left if U = T. 3. I opted for the return-by-value only method to safely handle move semantics (see other discussion Daniel started for why). Changing this to the unsafe version is as simple as replacing the basic operator definition macro (I have that code, too. Let me know if I should post this, too). 4. Pretty much all code which alluded to a specific compiler bug/support has been removed. This includes NRVO code. I'm still not sure what level of backwards-compatibility or specific compiler code we wanted so I just code to C++03/C++11. 5. I haven't added noexcept yet (mainly because I haven't had the time to learn more about noexcept yet). My testing has nearly all so far been done in VS2012 which has an "illustrious reputation" with standards compliance. I also have access to VS2010 and MinGW (GCC 4.7.2) so I'll try testing these later, but I don't have a setup for testing compilers in Linux/Unix/Mac or any other compilers we may want to support (Clang, Intel, Embarcadero/Borland, etc.). A few questions I have: 1. In v1 operators were always considered commutative/non-commutative. The composite operators take advantage of this fact, and I have the composite operators implemented with the same assumptions. Are there any composite operators we want to provide which make different assumptions (for example, a matrix has commutative add/subtract, but non-commutative multiply)? 2. I'm a little unsure if the <boost/iterator.hpp> include is still required. It compiled fine without it, but I haven't tried out all the features to see if it is indeed required. Anyone know why we should keep this include in v2? Feedback would be appreciated, thanks.

2 4

GSoC : Boost.Math Bernoulli Numbers
by Gaurav Deshmukh 26 Apr '13

26 Apr '13

Hi, I am Gaurav Deshmukh, CSE second year student. I am interested in the idea of adding support to Bernoulli's number to special functions in Boost.Math for GSoC-2013. I have the experience of using Boost libraries and generics in C++. I have experience to use git. I have also learned to use Boost Test upto some extent. I have tried to implement naive Akiyama–Tanigawa algorithm for second Bernoulli numbers using multi-precision boost class *'number' (cpp_dec_float_50**)*. I have attached two files. The header file *bernoulli.hpp* contains the function to calculate second bernoulli number for n<3000. *exampe.cpp *is made to test the bernoulli.hpp .

2 2

[gsoc-2013]Approximate string matching
by Yu Jiang 26 Apr '13

26 Apr '13

Hello, I'm Yu Jiang, currently a master student from Tsinghua University in China. I'm attracted by the idea of "approximate string matching" since it's highly related about my research and also my interest. I have seen in a previous discussion, another student proposed to implement some basic matching functions such as "edit distance" for boost. He said by using dynamic programming, the time complexity is O(m*n). However, if we give a threshold T and only report the exact edit distance if it's no larger than T, the complexity can be O(T * min(m,n)). I think sometimes we just need to decide whether the edit distance is small enough. Furthermore, I'm also interested in approximate string search. That is, given a query string word Q and a candidate word set S, find all the strings in S who have the edit distance no larger than a threshold T with the query string. This is very useful in many area such as data integration, and I have strong knowledge in fast algorithms to solve this. So, is it compatible for gsoc 2013 and for boost? Looking forward to your opinions. Thanks, Yu

3 4

[operators] The future of Boost.Operators
by Daniel Frey 26 Apr '13

26 Apr '13

Hello, for a long time there hasn't been any significant update of Boost.Operators and I had an easy job being its maintainer for the past 10+ years. I guess that will change soon. :) I would like to discuss the future of Boost.Operators, as several issues and options have piled up in the past. Here are some points to take into account: 1) Support for rvalue references to generate fewer temporaries. (where available) 2) Support for noexcept. (where available) 3) Support for constexpr if this is applicable at all. I haven't found the time to properly research it yet. 4) Allow dedicated commutative and non-commutative versions for several operators, leading to fewer temporaries for commutative versions in several cases. 5) Remove work-arounds for ancient compilers, general cleanup. I worked on a clean rewrite (called df.operators) which supports 1), 2) and 4) (and obviously 5)) and published it a few weeks ago on GitHub, see <http://github.org/d-frey/operators/>. It is meant to show one option, but it is not a suitable replacement for Boost.Operators in its current form. If it turns out to be useful as a test-bed for the next version of Boost.Operators, I will be glad to improve it into this direction but the future of Boost.Operators does not depend on it. That said, I'd like to invite anyone interested to have a look. If applicable to the future of Boost.Operators, please provide feedback on this mailing list. If feedback only concerns df.operators but not Boost, please don't spam the list and write to my private email, thanks! Some issues which need to be discussed/solved for Boost.Operators' future: 1.1) Which implementation should be used for maximum performance/compatibility? 1.1.1) Pass-By-Value as suggested by Dave Abrahams' article. (<http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/>) 1.1.2) Overloads for Pass-By-Const-LValue-Reference and Pass-By-RValue-Reference. (as in df.operators) See below for why I decided to create 1.1.2) as an alternative to 1.1.1). 4.1) Decide for a default. 4.1.1) Commutative by default (as the current version of Boost.Operators assumes), non-commutative if explicitly requested by the user. 4.1.2) Non-commutative per default, commutative versions need to be explicitly requested by the user. (as in df.operators) 5.1) The main issue is probably the base-class-chaining. 5.1.1) Keep base-class-chaining, makes VC++ happy. (apply EBO and keep the object size small) 5.1.2) Drop base-class-chaining, stop punishing the rest of the world for VC++'s inability to apply the EBO for multiple inheritance. (I might be a bit biased here…) 5.1.3) Any other option I fail to see? (If a MS-employee would like to provide some information on if/when the EBO-problem will be fixed (here or in private email), I'd be grateful. If it is already fixed, I apologize, but the last information I got about VS2012 suggests EBO is not applied for multiple inheritance.) I think this should be enough to get some discussion going… Best regards, Daniel Why 1.1.2) as an alternative to 1.1.1)? Consider the following test program: #include <iostream> #include <utility> struct A { A() { std::cout << "A::A()" << std::endl; } A( const A& ) { std::cout << "A::A(const A&)" << std::endl; } A( A&& ) { std::cout << "A::A(A&&)" << std::endl; } ~A() { std::cout << "A::~A()" << std::endl; } A& operator+=( const A& ) { std::cout << "+=" << std::endl; return *this; } }; // #define BY_VALUE #ifdef BY_VALUE A operator+( A lhs, const A& rhs ) { lhs += rhs; return lhs; } #else A operator+( const A& lhs, const A& rhs ) { A nrv( lhs ); nrv += rhs; return nrv; } A&& operator+( A&& lhs, const A& rhs ) { lhs += rhs; return std::move( lhs ); } #endif int main() { A a, b, c, d; A r = a + b + c + d; } The above code, compiled with G++ or Clang prints: A::A() A::A() A::A() A::A() A::A(const A&) += += += A::A(A&&) A::~A() A::~A() A::~A() A::~A() A::~A() A::~A() If you define BY_VALUE, it prints: A::A() A::A() A::A() A::A() A::A(const A&) += A::A(A&&) += A::A(A&&) += A::A(A&&) A::~A() A::~A() A::~A() A::~A() A::~A() A::~A() A::~A() A::~A()

7 30

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 26 Apr '13

26 Apr '13

> > I'm not ruling out the merit of a Boost.Thread threadpool. For me personally > > though, the hurdle is very significantly raised: you need to strongly prove > > to me why your proposed thread pool is much superior to a Boost.ASIO based > > threadpool. Otherwise I will zero score the GSoC proposal, because in the > > end we need other proposed projects more. > > Superior in what way? Performance-wise, interface-wise? What advanced > features would you want from a thread pool to make it superior to the > presented implementation? That's for the applicant to decide. Any proposal needs to be very significantly better than something based on existing features to pass muster not just with Boost, but with Google themselves. There is always an assumption against duplication of existing functionality just for the sake of it. Niall

1 0

[type_erasure] error in type-erased iterators
by Adam Wulkiewicz 26 Apr '13

26 Apr '13

Hi, iterator< ::boost::no_traversal_tag, ...> defines constructible<T()> requirement. This however musn't be meet in the case of incrementable and single-pass iterators. It should probably be moved to the iterator< ::boost::forward_traversal_tag, ...> Patch attached. Regards, Adam Wulkiewicz

1 0

Fwd: [gsoc 2013] boost.multiprecision
by Sagar Massand 26 Apr '13

26 Apr '13

Hi, I wanted to submit a proposal but I am not sure right now if I am going in the right direction.It would be great if you could guide me here. I was thinking of implementing karatsuba multiplication in the initial stages, complete with a testing of the implementation, and then move on to Schonhage-Strassen and other fast-fourier transform algorithms in the last one and half months seeing that our primary requirement is for numbers uptil 1000 digits. I was also thinking of the implementation of some other division algorithms like Goldschmidt, Newton-Raphson etc. A complete link to my proposal can be found below: https://docs.google.com/file/d/0B5iapFjtoO7GTVR2eGhJd2dXZHM/edit It would be great if you could give suggestions to improve this.Thanks. Regards, Sagar Massand

1 0

[gsoc-2013] Boost.Thread/ThreadPool project
by Dan Lincan 26 Apr '13

26 Apr '13

Hello, My name is Dan Lincan. I'm a 4th year undergratuate student in Computer Science at the "Politehnica" University of Bucharest and I'm interested in the project "Boost.Thread/ThreadPool". I have studied the documents provided as resouces and I would really appreciate if you helped me better understand this project. Are there any tasks that are meant to get solved for the proposal? How do I start? I am aware that it will not be an easy task at all, especially because I don't have much experience with boost, but I'm willing to learn and work as much as it is needed to get it done. Thank you for your time, Dan Lincan

3 15