September 2018 - Boost - lists.preview.boost.org

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