Article View: comp.lang.prolog
Article #3232Re: Prolog as a "real" language
From: Richard A. O'Keefe
Date: Tue, 12 Apr 1988 07:30
Date: Tue, 12 Apr 1988 07:30
49 lines
2968 bytes
2968 bytes
In article <1352@hubcap.UUCP>, steve@hubcap.UUCP ("Steve" Stevenson) writes:
> From article <855@cresswell.quintus.UUCP>, by ok@quintus.UUCP (Richard A. O'Keefe):
> > (5) It turns out that assignment to individual array elements is one of
> > the principal reasons for there being so little potential parallelism
> > in Fortran programs. There was a study which claimed to show that if
>
> Sorry, but you seem to have this fixation about Fortran and numerical
> processes be the same.
You cannot derive that from what I said. This particular point was about
updatable arrays, not numerical processing, and I specifically said Fortran
because the particular study I have in mind studied only Fortran programs.
> My question remains. Why not include "matrix" processing. Let's
> call them matrices to differentiate from the data structure. There
> very elegant proofs in real and complex analysis which use matrices
> and certainly seem to work just fine. Perhaps you mean the "unrestricted
> use of assignment in array structures."
If by this you mean some sort of collection which must be accessed fast
but does not require the ability to change individual elements, why not
indeed? There is a paper
D. Wise
Matrix Algebra and Applicative Programming
Conference on Functional Programming Languages
and Computer Srchitecture
September 1987.
I haven't got a copy of this paper, and I would be grateful if anyone who
has seen it would give me a more precise reference so that I can get a copy.
But the citation said "This approach [of emulating arrays using lists or
trees] may not be entirely invalid: [Wise 1987] provides an argument that
for certain numerical problems, trees are adequate."
> It's easy enough to think about a linear solver in prolog, but I
> want you to do Gauss-Seidel with a normal PDE in mind. Normal being
> LARGE and SPARSE.
Actually, what I said I want to do is linear programming (simplex method),
not a "linear solver", and "large" & "sparse" are exactly the characteristics
of such problems which make me think the existing resources of Prolog and ML
may be sufficient. They are certainly the characteristics which make arrays
as found in ADA or Modula-2 rather more clumsy for the application than one
would care for. Certainly these large sparse structures
I think we'll all be able to discuss the topic more intelligently when
we've had a chance to read the paper cited above, and I repeat my request
for a more precise reference so that I can do so.
Technical Details
Message-ID:
<870@cresswell.quintus.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!sri-unix!quintus!okReferences:
<855@cresswell.quintus.UUCP> <1352@hubcap.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!sri-unix!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: Prolog as a "real" language Message-ID: <870@cresswell.quintus.UUCP> Date: 12 Apr 88 07:30:57 GMT References: <855@cresswell.quintus.UUCP> <1352@hubcap.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 48