- Boost - lists.preview.boost.org

Formal Review of Proposed Boost.Histogram Library is FINISHED
by Mateusz Loskot 05 Oct '18

05 Oct '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library has been completed. Here is the quantitative summary of feedback received: * Reviews: 1. Klemens David Morgenstern 2. Jim Pivarski (off-list via e-mail to Hans) 3. Björn Reese 4. Steven Watanabe 5. Alex Hagen-Zanker * Non-review participations: 1. degski 2. Gavin Lambert 3. Seth 4. Mateusz Loskot I believe I've collected the names/numbers right, but please let me know ASAP if you think otherwise. I'd like to thank all the participants for their time and efforts. I'm sure Hans received lots of valuable comments and suggestions. FYI, the discussion threads are still open for new posts. Those won't be taken into consideration towards the review result though. I will do my best to announce the review results next week. Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Twenty years and time to retire
by Beman Dawes 04 Oct '18

04 Oct '18

The idea behind Boost was hatched in March, 1998, and the proposal document <https://www.boost.org/users/proposal.pdf> was released May 6, 1998. That makes Boost twenty years old, and makes me twenty years older. It is high time I retire from Boost; I haven't been able to contribute for some time now. Thanks to all of you who made Boost such an overwhelming success in the past and will drive Boost forward into a bright future! --Beman

21 20

Release notes for release 1.69
by Paul A. Bristow 02 Oct '18

02 Oct '18

To avoid forgetting to do it when release time comes, I would like to add some Math and Multiprecision library release notes for the next release 1.69 Is providing a PR for this file that way to do this? ( I speak Quickbook ;-) ) https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… (but it doesn't exist yet!) Thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

[histogram] Variance
by Bjorn Reese 02 Oct '18

02 Oct '18

The variance of individual bins can be obtained when using the adaptive_storage (via h.at(i).variance().) I am trying to understand the overhead of this feature. If I interpret the code correctly, there is a space overhead because each counter has to keep track of both the count and the sum of squares. The computational overhead is that the sum of squares has to be calculated for each insertion. Is this correct? If so, is there any way to use the adaptive storage policy without variance? Furthermore, why does variance() return the sum of squares? Should this not be divided by the sample size?

5 8

[asio] Order of asynchronous messages
by Florian Lindner 01 Oct '18

01 Oct '18

Hello, in a distributed application (only local are network) we are experiencing issues which *may* stem from the order of asychronous messages sent over sockets. We create a send buffer: auto buffer = std::make_shared<std::vector<double>>(); and fill it: buffer.push_back(some_data). This buffer is then given to our communication routine request = aSend(*buffer, recipient); to keep the send buffer alive we place it in a class attribute: bufferedRequests.emplace_back(request, buffer); The aSend method from above works like (asio is boost asio, of course) PtrRequest aSend(std::vector<double> const & itemsToSend, int recipient) { PtrRequest request(new SocketRequest); asio::async_write(*_sockets[recipient], asio::buffer(itemsToSend), [request](boost::system::error_code const &, std::size_t) { std::static_pointer_cast<SocketRequest>(request)->complete(); }); return request; } This way, we can check for completion using request->test(), which is set from the callback request->complete(). For checking of completed requests we have a loop, which is called reqularly void checkBufferedRequests(bool blocking) { do { for (auto it = bufferedRequests.begin(); it != bufferedRequests.end();) { if (it->first->test()) it = bufferedRequests.erase(it); else ++it; } if (bufferedRequests.empty()) return; if (blocking) std::this_thread::yield(); // give up our time slice, so communication way work } while (blocking); } which operates on bufferedRequests, that is a list<pair<PtrRequest, PtrBuffer>>. We use that, so that the sending peer is not blocked by a slow receiving peer. The sockets are created like tcp::acceptor acceptor(*_ioService); { tcp::endpoint endpoint(tcp::v4(), _portNumber); acceptor.open(endpoint.protocol()); acceptor.set_option(tcp::acceptor::reuse_address(_reuseAddress)); acceptor.bind(endpoint); acceptor.listen(); } Now we are having problems with mangled data that are unexplainable right now. - Is the order of requests guaranteed to be preserved? I think so, based that asio works on TCP. - What happens if there is another read or write performed on the socket. I think that there is no way to guarantee that this does not interfere with the order of the asynchronous send or queued requests. Last but not least: Do you see any potential problems with that code? Thanks a lot! Florian

3 2

[container][interprocess][intrusive][move] Removing support for old compilers
by Ion Gaztañaga 01 Oct '18

01 Oct '18

Hi, My libraries have supported quite old compilers, starting from Visual 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old compilers. The number of supported plus locally+regression tested versions has increased a lot these years and that's a lot of work with reduced benefits. I run locally for: - From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining C++03-C++11-C++14-C++14). - From MSVC 7.1 to MSVC 14.1, all released versions (default language standard). I also run boost regression tests for many of those compilers (see "igaztanaga-*" runners in https://www.boost.org/development/tests/master/developer/summary.html) The number of supported and tested compilers is now unmanageable for me as many of those have specific warnings/bugs that I try to fix. So I was thinking about reducing that list a bit dropping support for the oldest ones and replacing them with recent GCC/Clang from WSL (Windows Subsystem for Linux). My first idea is to drop anything older than 10 years, which means that the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008). I've reviewed some popular long support Linux distributions: -> RHEL 6 uses GCC 4.4. -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3 Microsoft no longer supports Visual 2008 (support ended on April 2018) but I can continue compiling and testing it at least for another year. Note that my libraries will continue support for -std=C++03, but I will not find workarounds or fixes for old GCC and MSVC versions. Thoughts, problems, comments? Best, Ion

6 9

[histogram] Formal review
by Bjorn Reese 01 Oct '18

01 Oct '18

Boost.Histogram contains useful and well-designed features, like excess (over/underflow) bins, and axis transforms to name a few. As this is a review, I am going to spent most time below on critical scrutiny. I. DESIGN --------- Iterators are const. This prevents us from bootstrapping the histogram with a prior distribution using STL algorithms like std::fill(), std::generate(), or std::sample(). The adaptive_storage does not work well with STL algorithms, because weight_counter is not an arithmetic type. See the Implementation section below for more detail. I therefore propose that the default storage policy is changed to something without weight_counter. The adaptive_storage has two responsibilities: data compaction and weights. Would it be possible to split this into two separate storage policies? I have no real use for arrival variance. I am not too fond of using operator() for insertion. The code looks like a function call with side-effect. I prefer an explicitly named member function. The axis::ouflow_type is oddly named. I suggest that this is renamed to something like axis::excess_type. II. IMPLEMENTATION ------------------ The implementation is generally of high quality. However, I did encounter the three problem areas listed below. (A) Integration with STL algorithms can be improved. Here are some examples: First, std::distance() does not work on a histogram with array_storage. This means that other STL algorithms, like std::any_of(), fails to compile. I solved this problem by copying the distance_to() function from the axis iterator to the histogram iterator. Second, std::max_element (and brethren) cannot be used on a histogram. Consider the following example: auto element = std::max_element(h.begin(), h.end()); Compilation fails for adaptive_storage because weight_counter has no less-than operator. Furthermore, compilation fails for array_storage because iterator_over<H>::operator= fails. It attempts to re-assign a reference, but accidentally triggers a copy-constructor instead. Letting the iterator store a pointer instead of a reference solves the problem. Apropos, iterator_over<H>::operator= does not return *this. Consider adding the -Werror=return-type compiler flag and a unit-test to that calls this operator. Third, std::inner_product fails to compile for adaptive_storage because weight_counter does not have a binary operator*. The inner product of two histograms is useful for calculating the cosine similarity, which can be used to compare two distributions. std::inner_product works for array_storage though. (B) Indexing and size use different types (int versus std::size_t.) I assume that this is because of the underflow bin, which is indexed by -1. I am not certain whether or not this is a real problem, but it does cause some oddities when stressed to the limit. For example, if we need a histogram that counts each unsigned int, then we get an "lower < upper" exception during construction: using range_type = unsigned int; auto h = make_static_histogram_with( array_storage<int>(), axis::integer<>(0, std::numeric_limits<range_type>::max())); It works if we reduce the end by 2, but then we are not collecting all values (unless we shift the range left by 1 and misuse the excess bins for the two missing values.) A possible solution could be to replace the -1 and N excess indices with an "enum struct excess { lower, upper }" and let operator[] et al use overloading on this enum. (C) Sometimes the compilation errors are nonsensical. For example: // Forgot to use make_static_histogram_with() auto h = make_static_histogram(array_storage<int>, axis::regular<>(10, 0, 1)); triggers an incomprehensible static_assert plus an error about a missing .shape() function. III. DOCUMENTATION ------------------ User guide is clear and pedagogical. I would like to see more examples that uses STL algorithms, such as calculating the CDF using std::partial_sum(), or calculating the cosine similarity of two histograms using std::inner_product(). Most examples use std::cout plus a comment to document the results of operations. Consider using assert() instead. Consider using a tabular layout similar to that of the C++ standard (or cppreference.com for that matter) on the Concepts page. Reference documentation is rather meager and shows implementation details. The documentation contains both a "Reference" and a "References" chapter which are completely different. Consider renaming the latter to something like "External references" , "Literature references", or "Bibliography". IV. MISC -------- I have spent around 15 hours on the review, mainly writing small examples that uses STL algorithms on Boost.Histogram. I am well-versed in the topic. I work with statistical distributions for real-time analysis of data, although I mainly dabble around in one dimension. I have written a library for online/streaming statistical algorithms. V. VERDICT ---------- While Boost.Histogram is a small niche library, it has a wide range of practical applications to warrant the inclusion into Boost. Boost.Histogram should be ACCEPTED into Boost, provided: 1. Reference documentation is finalized. I furthermore strongly recommend that the default storage policy is changed to something without weight_counter because of the various problems with STL algorithms. This recommendation is not a prerequisite for acceptance.

2 3

Median in Boost.Accumulators
by Lakshay Garg 30 Sep '18

30 Sep '18

Hello Boost Some time ago, I needed to compute the exact median for a stream of elements and after using Boost.Accumulators, realized that it only provides an approximation of the median and not the exact number. I rolled up my custom implementation of the algorithm and used it for my project. I wanted to check if people on this list might be interested in such an implementation for Boost.Accumulators in which case I can try to adapt my implementation and send a PR. Performance characteristics: For a stream of n numbers, the memory required is O(n). Median can be queried at any point of time in O(1) and adding all the elements costs O(nlog(n)) Lakshay

3 5

Will boost support DTLS / UDP?
by jupiter 29 Sep '18

29 Sep '18

It seems to me that Boost does not support DTLS so far, any plan and time line for boost to support DTLS?

2 1

CMake in Boost
by Robert Ramey 29 Sep '18

29 Sep '18

Many have expressed the desire that Boost support CMake. The Boost Board of Directors has emitted some sort of resolution to this effect - it's been a year. I would like to see progress in this direction. To this end I propose the following: a) Boost announce that a review of proposals to incorporate CMake into boost will be held in January 2019. This will follow customary Boost practices. b) Those who are willing and able to submit code/documentation and whatever else in necessary should do so before this date. I would anticipate at least two such submissions. As is the case with other reviews, I would not exist such submissions to be totally complete. But I would expect that they include enough for reviewers to test and practice with the proposed system. c) Prior to this discussions can be held on the list regarding the scope of such an effort. The review manager will distill these discussions to a statement of scope. This will be posted around 30 October 2018. I nominate myself (Robert Ramey) as review manager in this instance. Why would I do this? a) Boost needs this b) I've never been a review manager c) I'm a masochistic idiot. Robert Ramey

4 8