From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-06-15 05:04:36
somewhere in the E.U., le 15/06/2004
In article <c9nc0o$7d5$1_at_[hidden]>,
Deane Yang <deane_yang_at_[hidden]> wrote:
> Thorsten Ottosen wrote:
> > "Reid Sweatman" <drunkardswalk_at_[hidden]> wrote in message
> > news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAQ16IR/xA0BGKJURFU1QAAAKJ
> > AAAQAAAArLDup9m3ck+fnQ8diyZEOwEAAAAA_at_earthlink.net...
> > | Oddly enough, scientists is usually pretty
> > | conservative folk; they like what they know.
> > Is that so odd? Yesterday I talked with a matematician here in Sydney about
> > Fortran.
> > He uses Fortran because it is good enough for what he is doing. It would
> > probably take quite some
> > time for him to learn C++, so why should he?
> Agreed. It's the newcomers that we want to snare, before they've
> been indoctrinated into Fortran. New mathematicians tend to
> have at least some computer science training, so they will be looking
> for more than Fortran to write their code in. The competition will
> in fact be in the other direction, from languages like Ocaml.
Why would he want to learn C++ to do his computations?
What about better expressivity? If you need complex numbers, you
want to treat them as full-blown critters, and (most frequently, if not
always) not as simply a couple of reals. You want to write a+b and x*z,
and that the various components work correctly. If your favorite
plaything is even weirder, you definitely want to consider it as an
One thing should be kept in mind: a great many tasks which require
to too trivial math either will be carried out with ***prototyping***
software such as MATLAB or SciLab, or made into a custom software which
will only be run a few times. In that case, rapid deployment is
essential. In that case the object approach (including its C++
One would of course want that once the prototyping is done,
minimal effort would be involved to put into place a frequently-run, or
expensive-run (a.k.a. Cray-like "supercomputer" using) software. But for
one such software, how many smaller ones have been made (just to test an
Furthermore, Massive Mainframe Mastodons may perhaps not really
represent the future of supercomputing (think "cluster", and distributed
computing is a can of worms in and of itself). Waste is bad, but being
too clever for one's sake can also not be too good (just consider the
original Mac's handling of memory: it was designed to have large
programs run with tiny physical memory available, it was brilliant, it
was a reason why developers hated working on that platform...). So
perhaps not having the best-possible-ever optimization will appear
increasingly less significant. So the perceived efficiency edge of
FORTRAN will, IMHO, prove increasingly irrelevant. So why not learn C++,
which will *also* help with other programing tasks (GUI, etc.)?
There are other reasons, such as error handling, and the flow of
computing which must be adapted to it. I would favor (and this is the
approach I took with the libraries I submitted) an exception-based flow,
as it seems (to me at least) more natural that what FORTRAN, C and
others currently have.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk