September 2018 - Boost - lists.boost.org

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

[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

[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

[test] How to execute shell commands
by Mike Dev 28 Sep '18

28 Sep '18

Does the boost unit test frame work provide a way to write a test that executes a couple of shell commands? Specifically, I want to write a test that compiles a cmake project: https://github.com/boostorg/vmd/pull/4 https://github.com/boostorg/preprocessor/pull/20 what I need to do for that is essentially (on Linux): - mkdir <build_dir> - cd <build_dir> - cmake <source_dir> - cmake --build . Of course I can write a cpp program that uses std::system to execute those commands but I was wondering if there was a more direct way to do it. Best Mike

5 7

contract work
by Ggh 28 Sep '18

28 Sep '18

Hi, Sorry to pollute but: Available for contract work, code samples here: http://www.multi.fi/~ghaga/bak1 Cheers Greg

2 1

stufff
by Ggh 28 Sep '18

28 Sep '18

I don't know what I am up to: http://www.multi.fi/~ghaga/bak1/ http://www.multi.fi/~ghaga/ Thank you, Greg

1 0

Re: [boost] [cmake] Pull request announcement
by Bjorn Reese 28 Sep '18

28 Sep '18

On 09/14/18 13:44, Mike Dev via Boost wrote: > This will not address > - Testing [...] > In short: all the difficult stuff is left out ;) > The goal is not to present a solution that can replace b2 but to have > a minimal starting point upon which individual library authors or the > community as a whole can make iterative improvements. If and when BCM > (or an alternative) is accepted into boost, individual libraries can > then easily switch to this full-fledged solution and of course any > author can create a more complete CMake solution for his library at > any time (as some already have). In my experience, we want to have both an integration and standalone CMake file. This split is necessary to avoid problems with multiple instances of enable_testing() when using one library from another. * The integration file builds only what is necessary for integration into other projects. This is similar to what you are proposing. * The standalone file builds everything including test and documentation. This reuses the integration file to build the library itself. If we place your proposed CMake file in the library root, and dependent libraries start using that location, then it becomes difficult to later have the standalone CMake file in the library root, which is the more natural choice. So we should be cautious about where we place these files.

22 91