Boost logo

Boost :

Subject: Re: [boost] Demand for Boost libraries - was Math tools polynomial enhancements
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2015-10-31 14:18:46


Hi Robert,

I think you are asking the right questions

On 2015-10-31 17:10, Robert Ramey wrote:
> I think it would be hard to keep out. Also I think it would be very
> difficult to keep it from growing.
I think this is a general problem in boost: feature creep is all over
the place. Considering the little manpower that is actually developing
boost,
adding new features is likely to have long term consequences as it is
much easier to add stuff to boost than to remove it. There is also very
little oversight, once a library is accepted.
This is a result of the boost model: people propose their libraries to
boost, but boost does not have a list of "open problems". As there are
no requirements on what the libraries priorities are,
there is only little guidelines regarding the time after acceptance.
This model also has an impact of the later point you mentioned: while
there are people actively developing new libraries for boost,
there is not much checking whether it is relevant. People who do not
understand the problem are likely to stay away from the review and thus
biasing the review process: "I have never heard about coroutines or
fibers, apparently this is a thing. Someone else should review it before
I write something stupid".

> I'm actually more concerned about the demand for such a thing. I
> think it's very compelling. But as a member of the Program Committee
> for CPPcon 2015 I was very much struck by the lack of interest in
> topics related to mathematics and mathematical thinking. In
> particular there was a proposal for Algorithmic Differentiation
> implemented via TMP. In spite of strong advocacy on my part, other
> committee members were convinced that it was too advanced
> mathematically for the expected attendees. They might well have been
> right - if they were - it's even more disturbing to me.

I agree, this is disturbing especially considering how much scientific
high performance code is written in C++.
But I think this is a symptom of an underlying problem: there are no
math standards in the C++ world, no
standardized libraries or any agreement on interfaces. Therefore people
are spread over many incompatible libraries and thus the impact
of a single boost library is limited to the small fraction of scientific
programmers that happen to be compatible to that interface.

For example we have uBLAS as one competitor for linear algebra, but
currently Eigen and Armadillo are just better.
As boost has impact, there are a few projects which try to be compatible
to uBLAS (e.g. viennaCL and the thing i rolled myself)
but still this does not give this library some magical impact because
Eigen is so much better. I would say that uBLAS is therefore a "lost
cause"
as it has so many features that there is no way that the performance
problems can be solved within the given development constraints.

now, coming back to the TMP automdiff library: if there is no
standardized way to represent vectors and the boost way is not
favorable,
there is also no standardized way to represent vector valued functions
let alone their derivatives.
Without this, automatic differentiation is just not as useful as working
with single dimensional functions
is almost trivial, especially as there are many tools which just spit
out the right derivative and implementing that is only a few lines of
code.
On the other hand, as someone who wrote a few thousand lines of
derivatives of vector-valued functions in machine learning,
I would love to see a high performance TMP solution that I could just
plug-in.

Best,
Oswin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk