🚀 go-pugleaf

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.uk