Re: [boost] Demand for Boost libraries - was Math tools polynomial enhancements

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