[boost] Re: Boost Mathematicians

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-04 09:47:09

"David B. Held" <dheld_at_[hidden]> writes:

> I question whether C++ is the most appropriate language for this
> type of work.  Yes, we surely *can* reinvent the wheel.  But is it
> cost-effective?  And isn't Boost all about *not* having to reinvent
> the wheel?
>
> For most libraries in Boost, I can see a clear and obvious benefit
> from providing that library in C++.  But when it comes to
> algorithms, it is much easier to separate the interface from the
> implementation, so it seems that we should at least consider simply
> providing C++ wrappers for implementations that exist in other
> languages.  If there are clear benefits from reimplementing
> everything in C++, I'm all for it.  I just think it's worthwhile to
> look at all the angles before diving in.

The big advantage that C++ has over other languages is the ability of
metaprograms to use high-level domain knowledge to optimize arbitrary,
*readable* calculations.

Yes, it's worth "reinventing" all of those FORTRAN algorithms, because
using LAPACK et al. doesn't result in expressive code - every
combination of input types has to be handled by a different function
with some oddball name.  Furthermore, if implementations are not
generated programmatically, then they're bug-prone.  Even if they are
generated programmatically, they are limited (want to work on a matrix
of octonions or of small matrices?  Sorry -- you're out of luck).
Furthermore, pre-generated optimized calculations don't scale.  If
your FORTRAN library contains a routine to add 3 arrays efficiently,
it may not be able to do the same thing for 4 or 5 arrays.  With
expression templates you can just write the expression and let the
metaprograms deal with scaling up the calculation.

I don't mean to be sanguine about the very real hurdles faced by C++
numerical software, but we *do* have some real advantages that counter
low-level disadvantages such as the possibility of aliasing.  As the
sorts of calculations people want to do grow more and more complex,
the inability of statically-built FORTRAN libraries to adapt, and the
inability of those using the libraries to write code that is clear,
expressive, and maintainable, will become more of a liability.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com