Boost logo

Boost :

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2004-06-02 21:59:10

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David B. Held
> Sent: Wednesday, June 02, 2004 7:29 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost Mathematicians
> "Tom Brinkman" <reportbase_at_[hidden]> wrote in message
> > [...]
> > 2) We need a way to attract the best mathmaticians in
> > the world. How can we make the boost libraries an even
> > more attractive development platform for the
> > mathemiticians?
> > [...]
> I would guess that we would need to bring Boost up to the level
> of currently available libraries, in C++ or any other language in
> order to gain the attention of serious mathematicians. Since
> there is already a huge investment in other languages (such as
> GSL, which is written in C), this will be a significant hurdle. We
> should also ask whether C++ *is* the best development platform
> for mathematical applications.

I'd say (speaking as a soi-disant mathematician) you also need to find ways
to overcome the perception that "other languages do it faster and/or more
accurately." I've been the rounds on that one with some exceedingly
knowledgeable folk for the last fifteen years. The usual candidate is
FORTRAN, and there used to be some good reasons it was true. I think that
margin has been razored down until it isn't too meaningful any more, but any
library that wants to compete will have to really, really get it right
concerning a lot of things like error bounding, precision, error propagation
and handling (yeah, I know the STL design philosophy doesn't swing that
way), and then prove it on all the standard benchmark suites. About the
only significant advantages I can still see in FORTRAN's favor, apart from
the obvious one of the huge base of existing code, are the existence of
native operators for things like exponentiation (overloading, of course,
with a tiny performance penalty on some compilers), and the ease with which
FORTRAN lends itself to parallel processing (and the existing compilers for
doing that). I've seen one instance where a decision to switch heavy iron
platforms forced a rewrite of all existing FORTRAN supercomputer code at a
big research university (different loop nesting order); just modifying the
FORTRAN loops probably cost more than the cost of the computer, when you
factor in the time it cost all the research groups. You could hear the
screams in the corridors (only a small exaggeration ;) ).

I've done a lot of middlin' heavy math in C++, but it didn't have critical
consequences if it wasn't up to rigorous scientific standards (well, once);
a library used for actual scientific computing would have to meet those
standards. I think, though, that the perception problem would still be the
tougher problem, sadly. Oddly enough, scientists is usually pretty
conservative folk; they like what they know. And, as I mentioned, they're
often tied to particular hardware (although Boost isn't intended for the
supercomputer market, any parts of it accepted into the next spec will
eventually end up being used there).

Anyway, that's my 0.02 Zorkmids.

Reid Sweatman

Boost list run by bdawes at, gregod at, cpdaniel at, john at