- Boost - lists.preview.boost.org

[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

Formal Review of Proposed Boost.Histogram Library Starts TODAY
by Mateusz Loskot 27 Sep '18

27 Sep '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library starts TODAY, the September 17th, and lasts until September 26th, unless an extension occurs. =========== What is it? =========== Histogram is a header-only C++11 library, provides multi-dimensional histogram template class for counting, statistics and data exploration. The histogram class interface has been carefully designed to make the library * offer simple and convenient default behaviour * easy to learn and safe to use * convenient to use for one- as well as multi-dimensional analysis * compatible with STL algorithms * dependant only on C++11 standard library and optionally on Boost The author followed the "Don't pay for what you don't use" principle. The histogram class is customisable through policy classes, but the default policies were carefully crafted so that most users do not need to customize anything. The default policies guarantee the histogram to be safe to use as a black box, memory efficient, and very fast, where safety is related to overflow prevention and large values capping. This guarantees is one of unique features of the library in comparison to other implementations. The histogram class comes in two variants, which share a common interface: * static variant is optimised at compile-time to provide maximum performance, at the cost of reduced runtime flexibility and potentially larger executables; * dynamic variant is a bit slower, but configurable at run-time. Both variants of the histogram class provide optional serialization support implemented with Boost.Serialization. The library itself is header-only and the tests as well as examples can be built using both, Boost.Build and CMake. There are no dependencies required other than C++11 compiler. Optional dependencies include the GNU Scientific Library (GSL) and the ROOT framework from CERN which are needed the corresponding speed test programs used for performance comparison. A note on history: The library was first announced to the Boost community in May, 2016 [1] and the author received extensive feedback. Then, after a year of work posted second request for comments in April, 2017 [2]. =================== Getting the library =================== Checkout the `master` branch from the library git repository: https://github.com/HDembinski/histogram/ NOTE: The author follows the library submission process [3]: the master branch remains frozen for the period of the formal review, modifications in response to feedback should go to `develop` branch and big items may be worked and discussed via opening an issue on GitHub. Documentation: http://hdembinski.github.io/histogram/doc/html/ Website: http://hdembinski.github.io/histogram/ ================ Writing a review ================ Please, follow the official Boost formal review procedure [4]. If you feel this is an interesting library, then please submit your review to the Boost developer list (preferably), or the review manager to mateusz (at) loskot (dot) net. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. If needed, refer to the Boost Library Requirements and Guidelines [5]. Please, give constructive criticism! [1] https://lists.boost.org/Archives/boost/2016/05/229389.php [2] https://lists.boost.org/Archives/boost/2017/04/234410.php [3] https://www.boost.org/development/submissions.html#Review [4] https://www.boost.org/community/reviews.html [5] https://www.boost.org/development/requirements.html Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

7 54

[GitHelp] release version of boost from GitHub?
by Kostiantyn Ponomarenko 26 Sep '18

26 Sep '18

Hi, guys. What is the right place for getting the last/or-any (released) version of boost? This page provides the last release as well as others: https://www.boost.org. But I've got the impression that after Boost moved to GitHub and became "modular", the releases can be downloaded right from the GitHub "releases" page. So it looks like it is not the case, and my assumptions is wrong because when I go to the "releases" page on GitHub (https://github.com/boostorg/boost/releases) and download a release (let's say "boost-1.68.0") I don't get any libs inside. Could you please help me to understand this situation. Is the only place to get a release of boost is https://www.boost.org, but not GitHub? Is GitHub used only for development, or getting the latest changes which are not released yet? --- Kostia Kyiv, Ukraine

3 3

Formal Review of Proposed Boost.Histogram Library - LAST DAY
by Mateusz Loskot 26 Sep '18

26 Sep '18

Dear Boost Community, According to the review schedule, the formal review of Hans Dembinski's Histogram library lasts until the end of TODAY. Please, anyone who is aiming to post a review, hurry up! If there are members who have planned to post a review and still wish to do it but require more time, please speak up now indicating how much time you'd need. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Making Boost invisible
by John Maddock 25 Sep '18

25 Sep '18

Folks I have a bug report against Boost.Config that I don't know what (if anything) I should do about: https://github.com/boostorg/config/issues/243 The issue is this: lets say I build boost as static libraries with -fvisibilty=hidden because I want my application or shared library to *hide all boost symbols*. But there are some parts of boost which unconditionally make things visible - throw_exception is one particular culprit, but there are others, probably anything which uses BOOST_SYMBOL_VISIBLE in fact. Question: should we support this? If so how? The only thing I can think of is a user-defined macro which when set, disables symbol visibility. Thoughts? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

7 9

Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
by Klemens David Morgenstern 25 Sep '18

25 Sep '18

- What is your evaluation of the design? The design is excellent, in that is geared towards readability and performance. - What is your evaluation of the implementation? It looks highly optimized with a focus on only being as cheap as possible on CPU. I.e. only pay for what you use. - What is your evaluation of the documentation? Detailed, good examples, I understood everything. - What is your evaluation of the potential usefulness of the library? It's not my domain, but for anyone interested in data analysis this seems super useful. I think there should be more libraries from that domain, even tough it's not my primary one. - Did you try to use the library? With what compiler? Did you have any problems? Yes, I did last year, when it was still in development, I used MinGW 5 and MSVC 2017. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I looked into the library in depth last year and gave the author my feedback on several implementation details. - Are you knowledgeable about the problem domain? Not in depth, but I know the basics. And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Yes, definitely.

2 1

Interest in Unicode library for Boost?
by Zach Laine 23 Sep '18

23 Sep '18

I've been working on a Unicode library for submission to Boost, with an eye toward standardizing robust Unicode support for C++. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" may never happen, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. You can find the Github page here: https://github.com/tzlaine/text You can find the online docs here: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May, though it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 16

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 12:53, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 2:45 PM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: >> > Also, what if I don't actually call get() very often? >> >> If get() is not called very often, then I guess just using a plain vector and >> calling nth_element on it would be the best approach. >> >> > Is there any way to take advantage of make_heap()'s O(n) characteristics, >> > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, >> > just curious. >> >> The complexity of push_heap is actually O(log(n)) and not O(n) > > [make.heap] says: > > Complexity: At most 3 * (last - first) comparisons. > Correct! complexity for make_heap is O(n) and complexity for push_heap is O(logn). https://en.cppreference.com/w/cpp/algorithm/make_heap https://en.cppreference.com/w/cpp/algorithm/push_heap

1 0

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 10:59 AM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 08:39, Zach Laine via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > Could you compare and contrast this with the standard library's way of >> > computing a median, std::nth_element()? Yout just give it N/2 for 'n', and >> > it computes the median. >> >> The reason for not using std::nth_element was because I wanted >> to be able to query the median at any point of the sequence very >> efficiently. Had I used std::nth_element, I would have needed O(n) >> time for obtaining the median. For a case where I need to compute >> median after every single element, this would have required O(n^2) >> time for a sequence of length n. Here is my implementation in case >> you would like to have a look: >> >> https://gist.github.com/lakshayg/d27f29b4634cbfea3fc48c21b7b608ef > > I missed that the first time, thanks. > > Your implementation does not seem to support a windowed working set > (one element at a time is added and the oldest one removed). Is that right? Yes, that is correct. This approach does not support a window. > Also, what if I don't actually call get() very often? If get() is not called very often, then I guess just using a plain vector and calling nth_element on it would be the best approach. > Is there any way to take advantage of make_heap()'s O(n) characteristics, > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, > just curious. The complexity of push_heap is actually O(log(n)) and not O(n)

1 0

Re: [boost] Median in Boost.Accumulators
by Bjorn Reese 23 Sep '18

23 Sep '18

On 09/23/18 04:21, Lakshay Garg via Boost wrote: > 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. Boost.Accumulators does not seem to be actively maintained. > 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)) Sounds like you keep two ordered lists (e.g. std::set) of equal size. Then the median is the first element in the second list.

2 1

Formal Review of Proposed Boost.Histogram Library is HALFWAY through
by Mateusz Loskot 22 Sep '18

22 Sep '18

Dear Boost Community, We've reach half-way through the formal review of Hans Dembinski's Histogram library. The review lasts until the end of September 26th. If you are interested in applications for mathematics, statistics graphics, image analysis, and such, or in the Histogram library itself, please consider reviewing the Histogram library by the end of September 26th. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[filesystem] Library maintainers needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Filesystem needs one or more maintainers. This is a high complexity library, further complicated by (1) requiring both Windows and non-Windows implementation code and (2) needing a major upgrade for compatibility with the new standard library version shipped in C++17. Furthermore, there are constant Pull Requests and Issues that arise, and these almost invariably take a lot of time for the maintainer to process. My personal opinion is that Boost should deprecate the Boost library in favor of the standard library implementations, and do only minimal maintenance for several years until most users have migrated to C++17 or later. But that's up to the new maintainers to decide. Thanks, --Beman

3 2

[endian] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Endian needs a maintainer. This is a low/medium complexity library that requires only minor effort to maintain. --Beman

2 1

[timer] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Timer needs a maintainer. This is a simple low complexity library, and requires little effort to effort to maintain. --Beman

1 0

[build][testing] Tests naming in Jamfile
by Mateusz Loskot 21 Sep '18

21 Sep '18

Hi, I'm updating Jamfile-s of Boost.GIL and it made me wondering: For example: test-suite "boost-gil-test" : [ run promote_integral.cpp ] ; Apart from replacing the deprecated test-suite with alias, I wonder what is the recommended policy of naming the test suites, are there any rules? For example, should it be more or less hierarchical boost-{lib}-{testname} {lib}-{testname} {testname} or the name is completely local to/internal in a library and library maintainers are free to name as they desire? I could not find anything in the development guidelines and the testing policy docs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net p.s. Originally posted to boost-testing incorrectly https://lists.boost.org/boost-testing/2018/09/8446.php

2 2

[system] A non-allocating message() overload
by Peter Dimov 20 Sep '18

20 Sep '18

One of the objections against <system_error> is that message() needs to allocate memory, because it returns an std::string. This is true even for user-defined categories that can implement it without allocating, with a static message table. To address this, I'm thinking of adding the following overload to boost::system::error_category (with the intent of proposing it for std::error_category): virtual char const* message( int ev, char* buffer, size_t len ) noexcept; This is modeled after the glibc-specific version of strerror_r (and in fact has the exact same signature and behavior). If the implementation has a static character literal corresponding to `ev`, it returns it directly. If not, it composes an error message into the provided buffer, then returns `buffer`. Comments?

3 7

HoF Problems with Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

The following two bits of code compile ok with MSVC, but using LLVM/Clang produces the following errors. Using the code in print.cpp BOOST_HOF_STATIC_FUNCTION(simple_print) = fix(first_of( BOOST_HOF_LIFT(print_with_cout), BOOST_HOF_LIFT(print_with_range), BOOST_HOF_LIFT(print_with_tuple) )); produces the following error 1>./boost_hof_functions.h(45): error : templates cannot be declared inside of a local class 1>C:\boost_1_68_0\boost/hof/lift.hpp(90): note: expanded from macro 'BOOST_HOF_LIFT' 1>C:\boost_1_68_0\boost/hof/lift.hpp(105): note: expanded from macro 'BOOST_HOF_LIFT_CLASS' And BOOST_HOF_STATIC_LAMBDA_FUNCTION(print) = boost::hof::proj(simple_print); produces >./boost_hof_functions.h(51): error : non-const lvalue reference to type 'reveal_adaptor<...>' cannot bind to a temporary of type 'reveal_adaptor<...>' 1>C:\boost_1_68_0\boost/hof/lambda.hpp(241): note: expanded from macro 'BOOST_HOF_STATIC_LAMBDA_FUNCTION'] There are nearly identical errors with functions from in.cpp.

2 1

"is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

I receive the following build error when switching to LLVM toolset in VS2017 to build code using Boost 1.68. The code builds fine with MSVC compiler. 1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'

4 6