Path: utzoo!mnetor!uunet!husc6!purdue!gatech!hubcap!fpst
From: fpst@hubcap.UUCP (Steve Stevenson)
Newsgroups: comp.arch
Subject: Re: Supercomputer addresses and language use
Message-ID: <1113@hubcap.UUCP>
Date: 11 Mar 88 13:05:55 GMT
References: <5814@ames.arpa>
Organization: Clemson University, Clemson, SC
Lines: 41

in article <5814@ames.arpa>, eugene@pioneer.arpa (Eugene N. Miya) says:
> In article <24861@yale-celray.yale.UUCP> leichter@yale-celray.UUCP (Jerry Leichter) writes:
>>In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn Lisper) writes:
>>>... If we had a language that  . . . [comment about access]
>>>Isn't this a nice argument against using a language like FORTRAN in
>>>scientific computing?
>>
>>Nice theoretical argument - but it ignores the central issue:  Maybe the
>>REASON the scientific community like FORTRAN is that it ALLOWS them to "play
>>around".  In fact, "playing around" is an absolutely standard technique
>>in many large numerical codes; it's what makes them practical.
> But more to the pont is that a lot of codes are just artifacts
> (dusty decks) from days that much of this stuff did not fit on machines.
> This is why EQUIVALENCE is there.  They are also trying to get it out of the
> language with the greatest resistance.  It's playing around, but on
> a massive program scale.

I'd take exception to each view.  For example, take something like
Gauss quadrature which needs tridiagonal systems.  There is no
compiler (that I am aware of) which has "shape = tridiagonal" as a
primitive array shape. (I am, however, working on such a system)

Please also recall that one of the main walls facing both functional
and logic programming is the EFFICIENT implementations of very
vanilla numerical codes.  By efficient, I mean being able to compute
the solution AT ALL.  The problem is that assignments are based 
on known behaviour of the matrix and this actually allows for the
program to compute what is supposed to.  Otherwise, there isn't enough
memory anywhere.

The EQUIVALENCE problems comes about because most compiler folks have
spent more steam on condeming Fortran, rather than realizing that
it should be redone for the specialized numerical use.  We don't need
to write general software [e.g., accounting systems] in Fortran
anymore.  The question is how SHOULD we address the numerical problem.

-- 
Steve Stevenson                            fpst@hubcap.clemson.edu
(aka D. E. Stevenson),                     fpst@clemson.csnet
Department of Computer Science,            comp.hypercube
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell