From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.lang.apl
Subject: Re: SIGNUM of teaching numerical methods
Date: 21 Jul 92 01:49:36 GMT
Organization: Renaissance Technologies Corp., Setauket, NY.

In article <1992Jul20.160438.26974@csi.jpl.nasa.gov> sam@csi.jpl.nasa.gov (Sam Sirlin) writes:
>
>In article <1089@kepler1.rentec.com>, andrew@rentec.com (Andrew Mullhaupt) writes:
>
>|>... I can give a spec for a language which would answer _all_ my criticisms
>|> without even coming close to needing any _new technology_.

>I'd be interested in your spec. From your posts it seems it would include

>1. LAPACK

Not in and of itself, but it would be both a language in which LAPACK (and
its cousins) would be easily and effectively implemented. It would also be
able to use foreign code implementations of LAPACK at essentially no
penalty.

>2. sparse matrices & routines

No, but same as above. To some extent, sparse matrices are really just
another example of the higher levels of sophistication in scientific
applications since the bad old days. Remember - as computers bet bigger
and faster, the 'N' in everybody's problem gets bigger, and there is more
and more difference between orders of compexity which used to be practically
the same. This means that more and more complex algorithms will be wanted,
and no fixed group of large scale operations will do. So although the
language should make use of well understood large scale operations, foremost
among them vectors and matrices, and perhaps others, the language _must_
support full bandwidth operations on small things, and on small pieces of
big things. The language must be able to be close to full bandwidth in
terms of its flow of control - in particular even when no large scale
operations are used. Any language which satisfies these desiderata will
be OK for _all_ kinds of matrices.

>3. a "good" interface to other (compiled) languages, specifically Fortran
>  - including call by reference

This is a _must_. In fact more is needed. The language must provide as
near to full bandwidth interface in _both directions_. I.e. you have to
be able to call in and out without worrying about whether you're called
out or in already. Now you can't _really_ expect to go in and out etc.,
with just any language - more fancy interpreters don't allow this. But 
the desired language supports unlimited promiscuity with any standard
compiled language, and makes some provision for weird compiled languages
like C++.

>4. access to "primitive level coding"

Or what is the same thing, full bandwidth calls within the language
(so you won't really care) and full bandwidth calls into and out of
the language. So what's a primitive? Whatever you want. Also - you
will be able to re-implement your own versions of primitives, so
for example you will be able to use the R-SVD or Cholesky/Normal
equations for your 'quad divide'.

>I personally am interested in all but 2. (I don't generally deal with
>huge problems). So far though I've just added the linear solution part
>of LAPACK to APLc.

Actually, scientific computing often forces you to use a wide range of
numerical routines. The point is that you are translating significant
amounts of applied mathematics into finite representations on the machine,
just to cope with one formulation of a particular problem. Often, what
is just around the corner on the blackboard is a completely different
animal on the machine.

In some sense APL has come to grips with important issues here long before
other languages did - the unified approach to arithmetic, the providence
for convenient large scale operations _and_ large scale data, and a
healthy respect for continuity of abstraction (e.g. the rules about
empty arrays, etc.). APL missed in three ways - lack of open-endedness,
lack of provision for control-bound applications, and a failure to
realise the tremendous thirst for performance in the explosively expanding
use of computers.

Later,
Andrew Mullhaupt



Newsgroups: comp.lang.apl