Re: OONSTD: to early for standards? =?ISO-8859-1?Q?=EF=7C=A5=FF=FF=FF=FF?=

Axel Thimm (thimm@physik.fu-berlin.de)
Tue, 1 Jul 1997 21:48:49 +0200 (MET DST)

Barry Smith writes:
> *:> The aim of the list is to discuss these questions:
> *:>
> *:> * Are standard interfaces for scientific computing components in C++
> *:> a good idea?
> *
> *: Yes. However the issues in "scientific computing" are exceedingly
> *:complicated and the number of numerically oriented people who deeply
> *:understand the issues in object oriented design are very limited.
> *
> *: Now should be a time for experimentation and learning, not for focusing
> *:on premature standards. So, by all means, publish interfaces and
> *:discuss approaches, but I don't see how truly useful standards can
> *:be established for many years.

C++ is trying to show its presence in high performance computing for a long
time now with minor success. There are some nice `tricks' like Todd
Veldhuizen's expression templates making C++'s performance more appealing to
the scientific community, but another problem seems to be the incompatibility
of different libraries.

>From a developers point of view I would say, let the "Scientific C++" evolve
and let us pick the best at the end. From a users viewpoint this is
annoying. Standardisation of the C++ language itself has stalled many
applications and made people go back to Fortran. The current landscape looks
like the following example: A user chooses a matrix library and an iterative
solvers library. He tries to combine them by using wrapper classes,
inheritance and all the tricks he knows. Then he needs to go through the
sources to find out, why this does not work. Finally he gives up and writes
his own stuff.

I understand "standardisation" at the current time as identifying some basic
elements, that come up very frequently in scientific applications, like for
example objects from linear algebra. There already exists a large
knowledgebase concerning the numerical aspects (from C++ as well as from
Fortran libraries) and the problems with implementing them in C++. A library
dealing with low level objects like vectors and matrices (or operators) would
need to know about the requirements of these types, but not about the internal
representation. The goal of a standardisation would be to find a good
requirements interface.

Of course no standard should be imposed upon entities we do not fully
understand yet. This would stall development and new ideas.

Can we find a middle way to set up some week enough standardisation to allow
for new ideas to enter and strong enough to allow reuse and interoperability?

> *In fact I believe a basic challenge is understanding the roles, means,
> *purposes, and needs of those who might use standardized packages. I am
> *proposing some kind of "consumer survey" [...]

This sounds good, but how should one make such a survey? And who should be
asked?

> *I'd also like to suggest that while object-oriented design using C++ as
> *an exemplar is fine, the strategy of implementation ought to be
> *applicable to other important standards, too. [...]
> [...] I am also sceptical that the target
> *language -- as long as it supports an OO style -- matters a lot. We've
> *seen, for instance, a variety of codes implementing the algorithms in
> *NUMERICAL RECIPES for instance and these seemed to work fine.
> Absolutely, language does not matter [...]

I am not sure, if this is really true. I am not a programming language expert,
but I believe that especially C++ with its high expressiveness "creates" the
lack of a standard. I can imagine other languages like F90, that have stronger
support for "mathematical" arrays and less for OO, to already be better off in
this sense. Also a language could provide for more than binary operators and
pairwise evaluation, in which case the "quest for performance" in C++ would
not have led to the so many vector/matrix libraries.

My vision of a standard for "scientific computing in C++" would include a type
promotion mechanism, a categorisation of "operator" entities (e.g. matrices)
and the requirements thereof (That means I am only considering linear
algebra). This seems to me a basic and large building block for many
scientific applications.

> Barry
> *: Barry Smith
> * Jan Theodore Galkowski,

Best Regards,
Axel.

-- 
Axel Thimm   thimm@physik.fu-berlin.de thimm@ifh.de