Computer Science and Scientific Computing. Proceedings of the Third ICASE Conference on Scientific Computing, Williamsburg, Virginia, April 1 and 2, 1976

307 Pages·1976·17.99 MB·English

by  James M. Ortega

Computer Science
and Scientific Computing
EDITED BY
James M. Ortega
Institute for Computer Applications in Systems Engineering
NASA Langley Research Center
Hampton, Virginia
Proceedings of the
Third ICASE Conference on Scientific Computing
Williamsburg, Virginia
April land2, 1976
ACADEMIC PRESS New York San Francisco London 1976
A Subsidiary of Harcourt Brace Jovanovich, Publishers
COPYRIGHT © 1976, BY ACADEMIC PRESS, INC.
ALL RIGHTS RESERVED.
NO PART OF THIS PUBLICATION MAY BE REPRODUCED OR
TRANSMITTED IN ANY FORM OR BY ANY MEANS. ELECTRONIC
OR MECHANICAL, INCLUDING PHOTOCOPY, RECORDING, OR ANY
INFORMATION STORAGE AND RETRIEVAL SYSTEM, WITHOUT
PERMISSION IN WRITING FROM THE PUBLISHER.
ACADEMIC PRESS, INC.
Ill Fifth Avenue, New York, New York 10003
United Kingdom Edition published by
ACADEMIC PRESS, INC. (LONDON) LTD.
24/28 Oval Road, London NW1
Library of Congress Cataloging in Publication Data
lease Conference on Scientific Computing, 3d, Wil­
liam sburg, Va., 1976.
Computer science and scientific computing.
1. Electronic data processing-Congresses.
2. Science-Data processing-Congresses. I. Insti-
tute for Computer Applications in Science and Engi­
neering. II. Ortega, James M., Date III Ti-
tie.
QA75.5.I25 1976 001.6'4 76-25457
ISBN0-12-528540-X
PRINTED IN THE UNITED STATES OF AMERICA
Contributors
Victor R. Basili
Department of Computer Science, University of Maryland, College Park, Maryland
20742
/. C. Browne
Department of Computer Science, University of Texas, Austin, Texas 78712
Robert E. Fulton
IPAD Development Section, NASA Langley Research Center, Hampton, Virginia
23665
Anthony C. Hearn
Department of Computer Science, University of Utah, Salt Lake City, Utah 84112
Icko Iben, Jr.
Department of Astronomy, University of Illinois, Urbana, Illinois 61801
Harvard Lomax
Computational Fluid Dynamics Branch, NASA Ames Research Center, Moffett
Field, California 94035
Pedro V. Mar cal
Marc Analysis Research Corporation, Palo Alto, California 94306
W. M. McKeeman
Department of Information Sciences, University of California, Santa Cruz,
California 95060
Steven A. Orszag
Department of Mathematics, Massachusetts Institute of Technology, Cambridge,
Massachusetts 02139
R. L. Phillips
Department of Aerospace Engineering, University of Michigan, Ann Arbor,
Michigan 48105
Isaiah Shavitt
Chemical Physics Section, Battelle Memorial Institute, Columbus, Ohio 43201
and Department of Chemistry, Ohio State University, Columbus, Ohio 43210
Harold S. Stone
Department of Electrical and Computing Engineering, University of Massachusetts,
Amherst, Massachusetts 01002
Wm. A. Wulf
Department of Computer Science, Carnegie-Mellon University, Pittsburgh,
Pennsylvania 15213
vii
Preface
Scientific computing is a highly diverse activity spanning a multitude of disci­
plines. It draws on mathematics for answers to such classical questions as the
existence, uniqueness, and qualitative behavior of solutions of certain classes of
mathematical problems. Numerical analysis, considered by some to be a subset of
mathematics, provides rigorous analysis of algorithms, contributes to the develop­
ment of new algorithms, and attempts to finalize this work in the form of modules
(subroutines) for numerical solution of basic mathematical problems.
Scientific computing also draws on a number of areas in computer science and
computer engineering: computer architecture, computer systems, programming
languages, data management, symbolic computation, computer graphics, program
correctness, etc. The intelligent use of computers has always required, of course, a
detailed knowledge of the characteristics of the equipment being used. In the early
days of scientific computing on electronic computers, the interaction of the user with
the computer was direct and intimate. As operating systems, programming
languages, and other systems software became ubiquitous and more sophisticated,
the user needed to be aware of the details of the whole computer system, both
hardware and software. Moreover, with each new advent in computer architecture,
this cycle renews itself on an accelerating basis. For example, for the past few years
certain people in scientific computing have grappled directly with new hardware at
both ends of the computing scale: large vector or array processors, and mini- and
microcomputers.
As problems have become larger, the need to organize and manage the data of the
problem has become more acute and data management techniques probably will
become increasingly important in scientific computing. For much the same reasons
- large volumes of data, both input and output - the role of computer graphics also
is growing; it is assumed, and certainly hoped, that the era of large piles of output
listings is drawing to a close. Finally, several other areas of computer science, such as
symbolic manipulation and techniques for writing correct and reliable programs,
promise to have increasing impact on scientific computing.
The driving forces in scientific computing are, of course, the problems from sci­
ence and engineering that are to be solved. Unfortunately, however, the lines of com­
munication between mathematicians and computer scientists, on the one hand, and
practitioners in the various application areas, on the other, have not always been as
open and active as might be desired. Too many in the mathematical sciences are still
motivated by a conception of problems as they existed in the application areas years
or even decades ago. Conversely, many, if not most, of the applications areas have
developed over the years a substantial computing technology in relative isolation
IX
PREFACE
from parallel developments in other applications areas as well as in computer science
and numerical analysis.
A conference devoted to all the aspects of scientific computing would be so large
as to be unwieldly. Hence, a more modest goal was set: to bring together some of
the leading researchers in those computer science areas that have a direct bearing on
scientific computing, and practitioners of a few representative application areas. The
hope is that the exchange brought about by this conference - by the lectures as well
as by personal interactions - will help in a small way to increase the communication
between the various disciplines represented.
Whatever success the conference may have been is due to the efforts of a number
of people. I am indebted to the Program Committee, consisting of C. William Gear,
Peter Lykos, Harlan Mills, Martin Schultz, and John Shoosmith, for their efforts in
the early stages of planning, and to the representatives of the cosponsoring societies:
the Association for Computing Machinery, The American Chemical Society - Divi­
sion of Computers in Chemistry, the American Institute of Aeronautics and Astro­
nautics, the American Society of Civil Engineers - Structural Division, the Institute
of Electrical and Electronics Engineers Computer Society, and the Society for
Industrial and Applied Mathematics. Finally, the contributed papers and the local
arrangements were expertly handled by Robert Voigt, ably assisted by Mmes. Linda
Johnson and Barbara Porter of the ICASE staff.
J. M. Ortega
x
LANGUAGE AS A TOOL FOR SCIENTIFIC PROGRAMMING
Victor R. Basili
Computer Science Department
University of Maryland
ABSTRACT
Programming languages act as software development tools for
problems from a specific application area. The needs of the
various scientific programming applications vary greatly with the
size and style of the problems which include everything from
small numerical algorithms to large-scale systems. This latter
requires language primitives for a multitude of subproblems that
include the management of data, the interfaces with the system
at various levels, etc. One way of making available all the
necessary primitives is to develop one very large language to
cover all the needs. An alternative is to use a hierarchical
family of languages, each covering a different aspect of the
larger problem, e.g., a mathematical language, a data base man­
agement language, a graphics language, etc. The concept of a
family of languages built from a small common base offers a
modular, well-interfaced set of small specialized languages that
can support such software development characteristics as modu­
larity, reliability, efficiency, and transportability. This
paper discusses the use of the hierarchical family concept in
the development of scientific programming systems.
I. INTRODUCTION
Tools are designed to aid in the construction of a product.
They help produce a better product and make the actual building
process easier. They help in the automation of the various
stages of development making the more tedious, difficult, and
error-prone aspects easier and more reliable.
Scientific programming leads to the development of products.
What do these products look like? They vary in size and com­
plexity from library routines for basic mathematical functions
to self-contained programs encompassing basic algorithms to large
1
VICTOR R. BASILI
whole systems involving structural analysis (NASTRAN [NAS72],
NONSAP [BAT74], . . .) or control center operations (MSOCC
[NAS75], ATSOCC [DES75], . . .).
Tools have been developed to aid the scientific programmer
in product development. Consider the problem from an historical
perspective. In the beginning there was the bare machine. The
solution to the scientific programming problem was expressed as
a set of machine language instructions. The programmer developed
everything from scratch every time, working only with the basic
hardware. Almost immediately tools were developed to help
specify programs in more human-related forms improving the
machine environment in which the programmer worked.
The major emphasis in tools for expressing the problem
solution has been in the development of higher-level programming
languages. Such languages create an idealized, virtual computer
that corresponds to the thinking habits and capabilities of the
programmer, rather than to the limitations of the current tech­
nology.
One of the first tools developed was the library concept
permitting the reuse of existing subprograms. In this way common
tasks, such as mathematical functions, could be programmed once
and used over and over again. These subprograms were a first
step in defining a higher level set of the programming primitives
suited to the user's needs and the application area.
A second tool was the development of symbolic codes.
Assembly languages permitted the user to write in a symbolic no­
tation to specify the instructions and locations of the machine.
The use of mnemonics for instruction primitives made it easier
for the programmer to relate to the data of the program. This
higher level of specification was made possible by the assembler
which translates the symbolic codes into the real machine codes.
Higher-level scientifically-oriented languages, such as
FORTRAN and ALGOL, were developed to automate more powerful
2
LANGUAGE AS A TOOL FOR SCIENTIFIC PROGRAMMING
forms of specification. They incorporated specifications for
arithmetic expressions, data such as complex variables, control
structures such as conditionals and iteration, and data struc­
tures such as arrays. These higher-level languages are trans­
lated using compilers or macroprocessors or executed via inter­
preters.
A set of high-level, more general-purpose languages, such
as PL/1 and HALS/S [NEW73], offered facilities to the programmer
not available in languages such as FORTRAN. These facilities
included string processing and some control over the system
environment in the form of overflow and underflow control.
In order to more closely associate the terminology for
expressing the problem solution with the problem area, special
purpose application oriented languages have been developed.
Languages such as SNOBOL and LISP were developed early to handle
string and list processing problems, respectively. There has
been an ever-increasing number of very high-level languages that
involve the solutions of set-theoretic problems (e.g., SETL
[SCH73]), combinatorial problems (e.g., MADCAP [WEL70]), artifi­
cial intelligence based problems (e.g., SAIL [FEL72], PLANNER
[SUS70]), graph algorithmic problems (e.g., GRAAL [RHE72], GEA
[CRE70]), etc. Some of these languages have been called very
high-level languages as they raise the level of specification
far above that defined by the high-level languages, e.g., a
primitive like the union operator in SETL would require a sub­
routine in FORTRAN.
Besides being used to raise the level of the machine to help
the programmer express his program in the language of the problem
area, tools have been developed to improve the environment in
which the programs and programmer live. On top of the bare
machine, monitors were developed to run the computer without
stopping, automatically sequencing batches of jobs. This helped
make more effective use of machine time and removed the pro­
grammer from pushing buttons on the bare machine. Under such a
3
VICTOR R.BASILI
system, however, interactive development was lost. In time,
sequential batch processing gave way to demand systems. Using a
multiple programming system with a virtual memory, each user was
effectively given his own machine, in spite of the fact that he
was one of many users. These systems gave the user a greater
opportunity to share high-level resources such as text editors
and file systems. They returned to the programmer the ability to
interact with the machine, but this new software-extended machine
was more powerful and several levels closer to man's problem
areas.
Support tools have been developed which try to provide the
programmer with an environment for developing and analyzing his
programs at the level at which they are written. These support
tools include debugging aids, testing and evaluation aids, and
a variety of support programs including editors and data base
analyzers.
Given this large assortment of tools, the programmer needs a
mechanism for harnessing all these capabilities. Consider the
definition of a programming language in this context. A program-
ming language is a standardized notation used to express a prob
lem solution and communicate that solution to humans and com
puters. (Note that the idea of expressing that solution to
humans has gained considerable importance in light of the prob­
lems of correctness and maintainability.) The programming lan­
guage must provide the user with control over whatever primitives
are needed to express the problem solution and implement that
solution as a correctly executing program. All of the tools
mentioned earlier can be harnassed using programming language
notation.
The definition given here emphasizes several important
points which should characterize a programming language. These
include ease of expression, the ability to write correct, read­
able, implementable and efficient programs. The ability to com­
municate with various computers implies portability. Another
4
LANGUAGE AS A TOOL FOR SCIENTIFIC PROGRAMMING
important characteristic of a programming language is the ability
to reuse products developed in the language.
The next section discusses some of the capabilities and
characteristics a scientific programming language should have.
Section 3 recommends a method for defining a programming language
notation that achieves this set of capabilities and character­
istics using the concept of a family of languages.
II. SCIENTIFIC PROGRAMMING LANGUAGE NEEDS
The scientific programming notation must provide the pro­
grammer with a set of capabilities for solving his problem and
this notation should have characteristics that support the ease
of expression, correctness, etc., of the solution algorithm.
First, consider some of the actual capabilities a scientific pro­
gram via notation might encompass.
The most basic facility that is common across product size
and complexity is the ability to perform numerical calculations.
The notation should provide a basic set of arithmetic data types
including integer, real, complex. For operation on these basic
data types there should be a complete set of built-in operators
for each data type, along with complete libraries of special
functions. There should be clearly defined hierarchies of con­
versions, e.g., integer is a subset of real and real is a subset
of complex and mixed types are automatically converted to the
higher level type. The user should also have control over over­
flow and underflow with respect to the various operations.
There should be a variety of precisions for data types;
for example, there should be short and long reals, short integers,
etc. The user should have some control over precision in that it
should be easy to change precision across an entire program. One
way the need for a specific precision can be satisfied is by a
variable precision arithmetic package. This can be very in­
efficient however because the specified precision may not corres­
pond to the machine word size boundaries. Specific precision re­
quirements could be satisfied more efficiently by permitting the
5