- Boost - lists.boost.org

[proposed][histogram]
by Hans Dembinski 12 Apr '17

12 Apr '17

Dear Boost community, after another year of work, I hope to raise your interest once again in a much improved version of "histogram", a library proposed for inclusion in Boost. https://github.com/HDembinski/histogram http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582 The library can be build either with b2 or cmake. It compiles successfully with several versions of clang and gcc and has 99 % test coverage (the remaining 1 % are basically un-hittable branches). Boost-style documentation is available. The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. A histogram implements a quantisation of a space of input values. The space is divided into non-overlapping cells. Instead of remembering the exact values of a tuple in that space, one just increases a counter in the corresponding cell. This is the lossy compression, you only remember the count in the cell and not the original values. There are subtleties related to the counting if you want it to be safe and efficient. The library handles this for you. The standard policy implements intelligent counters which are fast, conserve memory, and are guaranteed to not overflow or get capped (capping happens when you use floating point numbers to count, like some implementations do). This is one of the two main feature of the library. The other main feature is that the library allows you to seamlessly create one or multi-dimensional histograms using various schemes to divide the input space. A so-called axis class handles the division into cells along each dimension. There are several ways how you might want to define the cells that divide the input space, and library offers you interesting options. For example, if one of your inputs is an angle, the library provides a special axis class for periodic input values. What's new: - Static polymorphism: The original version of the library solely used dynamic polymorphism to support different axis classes. This variant still exists, but the current version also allows you to use static polymorphism, implemented internally with boost::mpl and boost::fusion. This provides a speed-boost, which makes this library faster than the open-source competitors I tested (CERN's ROOT framework, the GSL, and numpy.histogram), in addition to the enhanced flexibility. - Arbitrary-precision counters: Counter overflow is now completely avoided by switching automatically to boost::multiprecision::cpp_int when the capacity of standard integer types is exhausted. - Extensibility: The library is now much more extensible and configurable. All relevant behaviour can be exchanged by using another (possibly user-defined) policy. The library provides default trade-offs that should work for almost everybody, but you can chose your own trade-offs. The new features were inspired by comments I got from the community. Now I am again at a point where I see the library in a very solid state. Best regards, Hans

1 0

[gsoc17] Help review Google Summer of Code proposals
by Niall Douglas 11 Apr '17

11 Apr '17

Dear Boost, Student proposals for Google Summer of Code are submitted, please help us decide which have the most merit. I have reduced the fifty something proposals submitted down to twenty seven which have some chance. To be able to view and rank the student proposals, please do the following: 1. Send to gsoc-admin(a)boost.org your Google login. We will invite you to view the student proposals on the Boost Google Drive. Until you receive the invitation email, you won't be able to view the proposals. 2. Go to https://goo.gl/forms/EVppdHsHMnjkcUoD3 which is a Google form where you can score the proposals. We have linked each proposal there to the Google Drive item and there you can rank a proposal between 1 and 5. Make sure you use the same email as your Google login in the form, otherwise we will ignore any forms submitted to prevent gaming the results. 3. Even if you can't rank all twenty seven proposals, try to do as many as you can and then PRESS SUBMIT at the end of the form (forgetting to press SUBMIT means we never get your rankings). The proposals are presented in random order per person so any work you do will be useful. 4. Please try to have your rankings done by Monday 10th. You may find reviewing the page at https://svn.boost.org/trac/boost/wiki/SoC2017 useful. 5. Finally, if you'd like to mentor any of the proposals, send to gsoc-admin(a)boost.org your Google login so we may invite you onto the Google website as a mentor. Many thanks in advance. Niall & Bryce

4 5

[Review Queue] SIMD Review on Hold -- Attn: wizards
by Michael Caisse 11 Apr '17

11 Apr '17

Hello Wizards - We need to postpone the review for Boost.SIMD while I compile answers to questions raised about the IP. I will report on my findings as soon as possible and either reschedule the review date or ask for the library to be removed from the queue. I apologize for the inconvenience and disruption of the queue. Take care - michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[release] 1.64.0 post-beta merges
by Rene Rivera 11 Apr '17

11 Apr '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> -- The Boost Release Team

13 56

[simd] Hardware support
by Bjorn Reese 10 Apr '17

10 Apr '17

Boost.SIMD only supports x86. Are there plans for ARM NEON and/or MIPS SIMD? What does Boost.SIMD currently do on unsupported platforms? Revert back to SISD?

13 41

[flat_set] When to sort?
by Vladimir Batov 10 Apr '17

10 Apr '17

I've been using boost::container::flat_set with quite a success until recently when I profiled my app to see that 30-50% of the run-time was spent in insert() for a container of around 50,000 in size. So, I had to replace boost::container::flat_set with a vector variation which inserts as a vector (no sorting). However, when it is the time to call begin(), end(), find(), it sorts once. That shaved the mentioned overhead off. Say, one run is down from 17s to 10s and the likes. I wonder if that should be the boost::container::flat_set default behavior rather than sorting the underlying container with every insert(). After all, as a user I do not care if the underlying container is sorted... until I start using/traversing it, right? Or maybe I am missing something in boost::container::flat_set which already allows me to do something of that sort?

11 37

Announcing CallableTraits' formal review next week (April 3rd)
by Louis Dionne 09 Apr '17

09 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library starts Monday, April 3rd and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Regards, Louis

4 4

Mathias Gaunard / NumScale relationship
by Joel FALCOU 08 Apr '17

08 Apr '17

Hi Niall, hi Andrey, I'm taking on to send you an email in private w/r to your questions on the list regarding Boost.SIMD, Mathias Gaunard and its relationship with NumScale. I'm adding Michael in CC: as he knows about the whole ordeal already and will corroborate my claims. Mathias has been one of the engineer I hired and then associate with to fund MetaScale, the company that will later become NumScale. He let the company after being ousted by one of our early investor for basically running the company into the wall and generally not knowing how to do business. He left for Bloomberg and started actually speaking about Boost.SIMD *as if* the internal information he gathered from within NumScale could be released to the public without our consent inclding internal benchmark report and road-map information. I imagine you understand why the cease&desist letter was then send. We have a bunch of other people using Boost.SIMD and they're doing fine (including other company and a bunch of OS project). I dont see why we'll be suing people using our open source software, which is different from using piece of the software he should not have. Since being laid off, Mathias kept trying to make our company and effort within open source fails by playing the victim and basically retelling history as he see fit. Also note that Mathias verbally threaten me that he will make this review a failure for us. This is the factual story of the whole thing: - 2003-2006 I worked in my PhD on something called E.V.E which was a EDSL in C++ able to supp0rot SIMD operations on PPC Altivec. - 2008 I'm now an assistant professor and work on a project called NT2 (that has been spoken about on the list a bunch of time) in collaboration with Jean-Thierry Lapresté which works on a huge amount of libm vectorisation code. Inside NT2, a remnant of E.V.E lingers and get worked on to support x86. - 2010 or some such, We start isolating the SIMD layer from NT2. At the same time, the university authorizes the release and open exploitation of NT2 as a whole in open source. NT2 and its internal soon-to-be Boost.SIMD is released under a Boost Licence. - around 2011, *I hire* Mathias to work on some part of NT2 and related project that culminates in 2012 at the creation of MetaScale. - We start speaking of NT2 and Boost.SIMD separately and it's probably around this time I raise the idea to make an actual submission to Boost. - 2014 for reasons that has no value being exposed here, Mathias leaves MetaScale and NumScale is funded to replace it. - 2015 The amount of people actively working on NT2 plummets and NumScale's team decide to reuse parts of Boost.SIMD into what bSIMD will become. - 2016 the rewrite is complete and the lack of support on NT2 make me pull the plug on the project. NumScale decide to open source back some parts of bSIMD, leaving this new Boost.SIMD made out of bSIMD be the sole remnant of this. And as your concerns goes Andrey about NumScale blocking PR or w/e coming into Boost.SIMD, The key point here is that Mathias is no longer affiliated with NumScale and has no information nor actual reason to speak on our behalf. NumScale has no plan to at short term release ITS OWN support for some architectures. This does not preclude anybody trying to undertake the effort to support an other architecture as long as yes, it is not Mathias pulling up the files we own he scavenged before leaving. We had had someone from ETH Zurich starting a port on QPX, something we also started but never finished due to other constraints. If this ever completes then, yeah it'll probably go inside the Open Source version if it's of enough good quality. We have various plan and discussion going on with different vendor and open sourcing more is planned at later date and depending on things I can not legally speak of because NDA. I'm planning to write or have Michael answer those issues publicly in a way I don't spread too much information that has nothing to do in public. I would appreciate if this line of discussion stay private for now until we address this properly in public. Meanwhile, I'm open to answer your other question. Best regards Joel

3 3

Re: [boost] [release] 1.64.0 post-beta merges
by Oliver Kowalke 08 Apr '17

08 Apr '17

Am 08.04.2017 1:44 nachm. schrieb "Daniel James via Boost" < boost(a)lists.boost.org>: On 8 April 2017 at 10:47, Oliver Kowalke via Boost <boost(a)lists.boost.org> wrote: > > I'd like to update > > - boost.context: updating documentation regarding to property > context-switch, apply property context-switch to Jamfiles in sub-directory > example I don't know enough about boost build for this one, but the change to 'include/boost/context/execution_context.hpp' seems unnecessary. It doesn't look like it will fix anything. The patch applies property 'context-switch' to the example code Jamfiles - no need to specify it at the cmd line. The definition of property context-switch was adapted to the public APIs of boost.context.

1 1

[gsoc17] GSoC next steps (was: Re: [gsoc2017]Satyam Pandey Copy GSoC 2017 Proposal writen by Ruoyun Jing)
by Niall Douglas 07 Apr '17

07 Apr '17

> Sorry for disturbing you at this time, I experienced a very bad thing > that Satyam Pandey, a student who sent proposal yesterday copied too > many sections of my proposal. I marked the sections red in the given > PDF.*I think the same pattern of GSoC proposal is common, and it does > not matter, but his proposal has too many same description as me. * Thank you for reporting this issue. It is unavoidable in Google Summer of Code that students copy one another and indeed sometimes pay another to write their competency test for them. We actually encourage students to study one another's applications and submit an even better application, this happened several times this year with the static map proposal. But we frown on failure to attribute sources, including failure to mention when the community or stackoverflow gave them help. And students who are later prove to be incapable of programming code at the level they advertised in their proposal are lifetime banned not just by us, but by Google. Last night I read every application and pre-eliminated half of them as I do every year so the Boost community doesn't waste their time with them. The calibre at the top this year is even higher than in past years, we have at least three truly superb candidates per project. It will be very hard to choose between them, and we will have to reject two superb candidates for no good reason other than only one student can do one project. You should see an announcement regarding community ranking soon. Watch this space. Niall

2 3