pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/13/90)
On 11 Dec 90 06:56:16 GMT, john@ghostwheel.unm.edu (John Prentice) said:
john> In article <PCG.90Dec10214715@odin.cs.aber.ac.uk>
john> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
john&pcg> [ ... crying on each other's shoulder about the extreme
john&pcg> naiveity of a lot of "numerical analysts" ... ]
john> And yes, I can accept that familiar notation can trap the unwary,
john> but what about all those people out there who know what they are
john> doing? I would hate to give up the convience of saying c=a+b just
john> to avoid some idiot failing to understand the limitations of
john> computer arithmetic.
Here you have a point -- but frankly I think that 'c=a+b' is not a great
convenience. Still, of my 2 alternative to Fortran, one, C++, is kind of
the ultimate in notational convenience; like Fortran [89]0, user defined
types, operators, ... Now that I think of it I think that one of the
very best languages for numerical analysis, with some of the very best
implementations, is Algol 68. Too bad it has almost faded away. My other
alternative is a bit less traditional:
pcg> Given that a language should not be preferred (or avoided) because of
pcg> its familiar notation, things like Scheme can become attractive.
pcg> Scheme has excellent performance (a little more work on compilers can
pcg> yield MAClisp style ones I think), and it has inbuilt support for things
pcg> like infinite precision numbers, rationals, ... that ought to be used
pcg> far more in numerical analysis, but are not because Fortran does not
pcg> have them. Scheme has also fairly powerful abstraction facilities, so
pcg> that for example adding interval arithmetic (another thing that is not
pcg> in Fortran, and thus ignored by many) is not that difficult, and it has
pcg> also excellent exception handling and library facilities, and so on. It
pcg> does not a familiar looking syntax, but nobody should care.
john> I am not familiar with Scheme. Could you point me at a reference so
john> I can learn about it? Thanks.
Well, there is an introduction to programming, Abelson & Sussman, that
uses Scheme as vehicle. I think that even clearly you do not need to
learn programming from scratch, seeing that book is the best way,
because the Scheme programming style is quite different from Fortran,
and looking at it as if a beginner can be most interesting.
Scheme is a Lisp dialect, more or less (hand waving here!) descended
from MAClisp. MAClisp and Scheme were strongly influenced by MACsyma,
which even if it was a symbolic algebra package, had substantial
numerical components, and was written in MAClisp. Numerical support in
Scheme is particularly strong; infinite precision numbers are included
in the base language (as well as rationals, but I do not think that this
was a good idea though). It is easy to add new operators and data types,
and to create high level functions that strongly resemble common
mathematical ones (e.g. summation). The syntax is unconventional, like
Lisp, but easily managed with structure sensitive editors.
It is well known that the MAClisp compiler for the PDP-10 generated code
at least as good as the DEC Fortran for the same machine, because it had
been tuned to support MACsyma. Existing Scheme implementations, even
those that generate C or directly machine code, are not as efficient,
even if usually pretty good. Many Scheme implementations support linking
in procedure written in more conventional languages like assembler, C or
Fortran.
Scheme is one of the most widely implemented languages, running on all
of the popular architectures, is well defined by a clear and concise
report, ...
One of my favourite Scheme implementations is T, from Yale. Another is
Scheme->C from the DEC WRL.
Scheme is discussed in comp.lang.scheme. Note: I am not a regular user
of Scheme, I usually use C, because most of my work is Unix kernel
hacking. On the other hand, I am going to write an OS kernel, and I am
seriously considering writing it in Scheme (or Algol 68!) instead of
C++. The *only* stumbling block, like for Algol 68, is my inability to
find an implementation with a *retargetable* compiler that also
generates code for the 386. I would then hack it not to use GC (bad for
a kernel, whre I can allocate everything nearly statically).
john> [ ... about computational physics lacking an established tradition
john> and academic respectability as a subject of its own ... ]
Well, this is not really languages, but so what? :-). I can console you
a bit by saying that physics itself was a bit in the same state three
centuries ago. Also, much of the important results of physics in the
last decade have been done by computational physicists. Things may well
be turning around. Hold steady!
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukprentice@hydra.unm.edu (Colston Chandler PHYSICS) (12/13/90)
In article <PCG.90Dec12181318@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >....Still, of my 2 alternative to Fortran, one, C++, is kind of >the ultimate in notational convenience; like Fortran [89]0, user defined >types, operators, ... Now that I think of it I think that one of the >very best languages for numerical analysis, with some of the very best >implementations, is Algol 68. Too bad it has almost faded away. > Whatever did happen to Algol? You see alot of the old ACM algorithms programmed in it and it looked rather interesting. I can remember seeing satellite ephemeris programs written in it 20 years ago, but you never hear of it anymore. So how is C++ for scientific programming? In particular, what exactly does an OOPS language do for numerical programming? Also, do you (or anyone else) have any suggestions for a good language for doing numerical programming on a parallel computer? I am interested in fluid dynamic like codes, so I need to maximize performance. I am looking at domain decomposition problems where I may have somewhat unstructured grids. The recent C versus Fortran war has at least convinced me that I should look more seriously at least at C for such things. Is C++ or Ada better? > > ... (after a discussion of Scheme) ... >Scheme is one of the most widely implemented languages, running on all >of the popular architectures, is well defined by a clear and concise >report, ... > I will look up the reference you gave on Scheme. Sounds like something I should at least know about. > >john> [ ... about computational physics lacking an established tradition >john> and academic respectability as a subject of its own ... ] > >Well, this is not really languages, but so what? :-). I can console you >a bit by saying that physics itself was a bit in the same state three >centuries ago. Also, much of the important results of physics in the >last decade have been done by computational physicists. Things may well >be turning around. Hold steady! > I appreciate the support! By the way, you are right that my discussion about the lack of academic respectability (good way to put it) of computational physics is not really a subject for this group, but it IS in a way, in the sense that so much of the recent flame war between C and Fortran (which I certainly have done my part to fan) is fueled by the problems that computational scientists face in having to balance understanding of their principal discipline with an understanding of computers. One has to sympathize somewhat if they are resistant to learning new languages unless there is a major advantage. It is really hard to keep up with your principal discipline and still keep up with the rapid developments in CS. That is alot of why it may appear that the Fortran community is so entrenched. It is not that these people are stuck in the past, it is just that they already have their hands full and need more than one or two reasons to switch from Fortran to something else (these comments are really pointed at the newsgroup in general). I don't think this is something the bulk of the CS community really understands. On the flip side, too many scientists resist every learning to program worth a damn and they do often ignore the bulk of CS research. Here is a need for another interdisciplinary activity, explaining CS to non-CS oriented scientific community. For example, I am a member of the ACM and have received the Communications for years. Yet I don't have the foggest idea of what most of the articles are about. I doubt most readers of the Communications would understand the articles I read in Physical Review B either. BUT, I need computers to do my job, CS people don't need theoretical solid state physics to do theirs. Be that as it may, I still don't have time (or interest to be honest) to make sense of the jargon in alot of these articles. It is therefore hard to keep abreast of the CS developments that ARE of improtance. The same is true of languages. There really is a need in the scientific community for people to translate these things. Well, pardon my diatribe. These sort of issues tend to excite ones passions (as is evident from the past weeks of controversy!). John john@unmfys.unm.edu
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (12/13/90)
> On 13 Dec 90 08:49:16 GMT, prentice@hydra.unm.edu (john@unmfys.unm.edu) said: John> In article <PCG.90Dec12181318@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >....Still, of my 2 alternative to Fortran, one, C++, is kind of >the ultimate in notational convenience; like Fortran [89]0, user defined >types, operators, ... Now that I think of it I think that one of the >very best languages for numerical analysis, with some of the very best >implementations, is Algol 68. Too bad it has almost faded away. John> Whatever did happen to Algol? You see alot of the old ACM John> algorithms programmed in it and it looked rather interesting. What we obviously need is GNU-Algol-68, maybe shorted to gnugol, or even just gol. Any volunteers for the implementation? ------------------------------------------------------------------------ > ... (after a discussion of Scheme) ... >Scheme is one of the most widely implemented languages, running on all >of the popular architectures, is well defined by a clear and concise >report, ... John> I will look up the reference you gave on Scheme. Sounds like John> something I should at least know about. While you are looking at Scheme, you should probably also look at T. T is a variant of Scheme for object-oriented LISP-looking programming which was developed at Yale. I have read the report, but have not yet had any time to play with the language.... ------------------------------------------------------------------------- John> I appreciate the support! By the way, you are right that my John> discussion about the lack of academic respectability (good way John> to put it) of computational physics is not really a subject for John> this group, but it IS in a way, in the sense that so much of the John> recent flame war between C and Fortran (which I certainly have John> done my part to fan) is fueled by the problems that John> computational scientists face in having to balance understanding John> of their principal discipline with an understanding of John> computers. The same problems exist in my field (ocean modelling), but are probably even more acute. John probably gets in trouble by being called a "computer hacker", while I get in trouble by being called a "mathemetician" just because I pay too much attention to getting the right answer from the mathematics that goes into the computer models! After all, the only thing that matters is getting pretty pictures, right? On the "respectability" subject, I was at the Supercomputer Computations Research Institute at Florida State a few years back when they tried to get together degree program in "computational science". The plan eventually failed. From my limited exposure to the actual politiking, it seems that it failed because: (1) The narrow view of "computational science" looked like it was simply a specialization within the applied math department. (2) The broad view of "computational science" was seen to be too large to fit into a reasonable Ph.D. program. (3) None of the existing departments wanted to risk giving up any of their current or prospective graduate students to yet another competing department. ----------------------------------------------------------------------- -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/21/90)
On 13 Dec 90 08:49:16 GMT, prentice@hydra.unm.edu (Colston Chandler
PHYSICS -- or John Prentice?) said:
prentice> In article <PCG.90Dec12181318@odin.cs.aber.ac.uk>
prentice> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> ....Still, of my 2 alternative to Fortran, one, C++, is kind of
pcg> the ultimate in notational convenience; like Fortran [89]0, user defined
pcg> types, operators, ... Now that I think of it I think that one of the
pcg> very best languages for numerical analysis, with some of the very best
pcg> implementations, is Algol 68. Too bad it has almost faded away.
prentice> So how is C++ for scientific programming? In particular, what
prentice> exactly does an OOPS language do for numerical programming?
Well, there are plenty of fairly good quality numerical libraries for
C++. The benefits of OO programming for numerical analysis is that even
numerical problems often have fairly sophisticated structure, and OO
programming is good at describing and changing structure.
While it may be a major undertaking to change an existing program in
Fortran to use sparse instead of full matrixes, it is much less of a
hassle in OO languages.
Changing your program from single to double precision and
viceversa is trivial in any language with type declarations; with OO
programming it is also almost as trivial switching from straight
floating point to interval arithmetic or arbitrary precision integers.
C++ also gives fairly concise notation, and it is easier to see the
shape of an algorithm in C++ than in Fortran, because of the superior
data abstraction facilities provided.
Cleverly used, C++ is at least as efficient as Fortran, or even more so
(const, inlining, ...), and the famous aliasing/optimization problem can
be usually worked around by the use of compiler directives or explicit
temporaries (the better solution, it makes things more obvious). On some
popular machines you get better speed by translating Fortran to C/C++
then using the Fortran compiler directly. Note that many of the proposed
extensions to Fortran as in Fortran [89]x are already present in C/C++.
prentice> Also, do you (or anyone else) have any suggestions for a good
prentice> language for doing numerical programming on a parallel
prentice> computer? I am interested in fluid dynamic like codes, so I
prentice> need to maximize performance. [ ... ] Is C++ or Ada better?
Ah, this is some hard question. Very hard. C is essentially like Fortran
in this, in that compilers analyze the source to find opportunities for
parallelism, and rewrite the program... Trickery.
Sadly, the state of the art for micro-parallel (vector/SIMD) languages
is not that advanced. Some interesting research is being done with
functional languages, but I am skeptical on functional languages (too
long to explain why). Moreover current functional language
implementations are not numerically oriented.
For coarser parallelism there is Concurrent C/C++ and a number of thread
packages for C/C++. Also, Ada tasking, but there are precious few
implementation of Ada that map tasks on threads running on multiple
processors. *Lisp for the Connection Machine is a rarely affordable
alternative.
Yeah, now that I think of it, I can remember several thread libraries
for C/C++, some of them multiprocessing (different threads run on
different CPUs), but (of course) none for Fortran. Interesting.
pcg> Scheme is one of the most widely implemented languages, running on
pcg> all of the popular architectures, is well defined by a clear and
pcg> concise report, ...
prentice> I will look up the reference you gave on Scheme. Sounds like
prentice> something I should at least know about.
I would suggest having a look at T and Mul-T; T is an implementation of
(something that is nearly identicaly to) Scheme with a fairly good
optimizing compiler; Mul-T is the parallel version of T. I have used a
little bit T, and it is large but nice. I have not used Mul-T.
Incidentally, a good list with discussion of Scheme implementations is
in "arisia.xerox.com:/pub/scheme/scheme-implements.txt".
prentice> [ ... the difficulty for computational physicists have in
prentice> styaing tuned with CS progress like new languages ... ]
But this is problem that engineers and physicists have! Their main
subject is not maths, it is engineering or physics, but maths are a very
important part of their training, and those that do research in
engineering or physics have to keep very current in maths as well;
indeed they have made a number of contributions to maths.
Computer Science is this respect is like Mathematics, an abstract
discipline that is ancillary to many others. Learning a new language is
(well, should be) like learning a new method for doing eigenvalues for
an engineer or a physicist.
It is a pity that Computer Science itself does not have the traditional
respectability of Mathematics, so that people that delight in learning
new ways to tackle the eigenvalue problem do not delight in learning new
languages or programming technology.
Is this a problem with languages or other CS technology that is more
offputting than maths? No, I think, because while CS people do care (too
rarely!) about human engineering issues, e.g. in designing languages
that are descriptive and concise, maths people don't; most mathmatical
notation is horrid, and most theorems could often be drastically
simplified and streamlined both in exposition and substance. But people
are used to and put up with cryptic maths, while they make excessive
demands of CS.
Ahh. Maybe this is why people think that Fortran is like maths: it is
cryptic and ill structured... :-(.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk