: 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.
The target architecture determines a lot, too. Now, a lot has been achieved over
the years with writing compilers for various architectures, notably the FORTRAN
compilers for the Cray and for the IBM Vector thing, but the appeal of C and C++
is, I believe, one can have very close control of how objects are represented
in memory. Unfortunately, it isn't likely a standardized package will consider
or even adapt easily to such specialized representations. The repspec idea of
Ada is sort of what one would like to do, but Ada's supporters and implementers
got too pragmatic to develop that where it could go. C++ has nothing like it.
FORTRAN is computationally simple -- so in a sense a compiler can have its
way with the object code -- but C++ inherits from C its large user group
who are control freaks.
: >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.
Well, there's a middle ground here, too, which I often do -- in fact, am doing now.
That's to take a package written in FORTRAN and recode it in whatever language
is supported, in my case Ada95. If one can call routines compiled from other
languages, there must be some requirements level motive to recode in source.
[snip]
: > *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?
Well, deciding on a sampling frame is a crucial first decision in such a
survey. That it is difficult to do is no reason not to do the survey. Once
it is decided, one can then make rational assessments on how to get a
representative sample of that frame. To decide a frame, one needs to
determine specific objectives, and adopt some model of costs or loss,
that is, how much missing the boat in various directions will penalize,
if only in lost opportunity. Semipublic standardization committees have
little experience at this. The commercial MathWorks, SAS, SPSS,
Statistica, etc. people probably have done this at one time or another.
It's clear that such an effort isn't going to get far without some kind
of budget. But what does anyone expect? A high quality standard doing a lot
for most people for free?
: > *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.
When I think of standardization and I think of C++, I have a hard time knowing
what people mean. After all, there isn't one C++, there are many versions of
C++, each with quirks and, annoyingly, most of those quirks not being in
syntax, but in subtle semantics for how things are done. I'm only half
serious, but if one were going to standardize anything for numerical work,
it seems to me you'd want to start very simply and generally: Like with
a uniform LISPish prefix polish form.
Or maybe its possible to go to a much higher level keeping a C++ syntax. But
does anybody in this group really want to ponder developing a new language?
I doubt it.
: 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.
But for really high performance computing, there are, too, questions of
stride and of sparse arrays and dealing with these efficiently, and of
explicit control of interprocessor transfers.
: > Barry
: > *: Barry Smith
: > * Jan Theodore Galkowski,
: Best Regards,:
Axel.
: --
: Axel Thimm thimm@physik.fu-berlin.de thimm@ifh.de
Jan Theodore Galkowski,
jan@digicomp.com
jtgalkowski@worldnet.att.net