Welcome to the Object-Oriented Numerics List (oon-list and oon-digest).
The purpose of this list is to discuss scientific computing in
object-oriented languages.
Subscriptions to the list have levelled off at the 300 mark,
so it is time to declare the discussion open.
The list will remain unmoderated on a trial basis. Standard
netiquette applies: trim your quotes, no one-line replies, no
administrivia, no flames. To post, send mail to:
For a primer on using the majordomo software (including subscribing
and un-subscribing), send a message containing the line "help" to
To start us off, I offer the following incomplete list of topics
to consider:
* Language issues
Some object-oriented languages seem more suitable for scientific
computing than others. Languages providing operator overloading
(for expressiveness) and templates (for type abstraction)
have a definite advantage.
Candidate languages for OON include C++, Fortran '90, Fortran'2000,
Java, Ada, Sather, Eiffel, Smalltalk, Oberon, and others I overlook.
Are there winners and losers in this bunch?
* Performance
Some object-oriented languages (and I think of C++ in particular)
have performed very poorly when pitted against Fortran 77. To
achieve reasonable performance, many developers use mixed language
programming: C++ provides the elegant OO framework, but F77 does
the real number crunching.
Recent advances in compilers and language techniques may
resolve these performance problems. There are even reasons
to suspect that C++ may surpass the performance of Fortran 77.
Such performance comparisons between languages are hard to
do fairly. If we allow unlimited twiddling by expert coders,
we risk measuring compiler performance rather than the
languages themselves. Perhaps this is appropriate.
If we compare codes written at similar levels of abstraction,
we ignore the careful hand-tuning which is an important
factor in the performance of real-world scientific codes.
How should performance comparisons between languages
be reported?
* Productivity
Some advocates of object-oriented languages claim a productivity
boost awaits Fortran programmers who make the switch. A recent
study appears to suggest otherwise (*). Will object-oriented
languages *really* make us more productive?
(*) In R. F. Boisvert, ed., Quality of Numerical Software, Assessment
and Enhancement, Chapman & Hall, London, 1997. Anyone willing
to summarize the relevant chapter(s)?
* Teaching object-oriented numerics to the masses
Many Fortran programmers who migrate to C++ produce what Scott Haney
has dubbed "C++tran": Fortran with semicolons. Object oriented design
has a steep learning curve, and you don't reap the benefits
until you're well along that curve. What incentives can we offer
scientific programmers to make that investment? Assuming they're
willing to make it, how can we teach object-oriented numerics
to them effectively?
* Design of object-oriented numerical libraries
Modern programming languages allow library developers to abstract
away enormous amounts of detail from the user. We can write
A = product(B, C);
for a matrix product on our desktop Mac. The same code compiled
for a massively parallel supercomputer can turn into a distributed
representation, parallelized Strassen matrix multiplication.
Numerical library developers have accumulated a wealth of techniques
for the design of object-oriented libraries, but many tough problems
remain.
One of the many promises of OOP is the vision of reusable objects
meshing together smoothly to produce complex applications: linear
algebra package A cooperates with interval arithmetic package B,
finite element library C and visualization package D. But the reality
isn't so pretty. Such libraries are, as a rule, incompatible, and
substantial hacking is required to glue them together. Do library
developers need to agree on standard semantics for numerical objects?
* Design patterns for scientific computing
Are there recurring patterns of interaction between objects which
are unique to scientific computing? Would it be useful to hunt
out such patterns and record them as "standard designs" for
programmers to follow?
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST