EASL(ID:5147/eas009)
continuous simulation language
for Engineering Analysis and Simulation Language
continuous simulation language
S. Schlesinger and L. Sashkin
Aerospace Corporation, San Bernardino, California 1966
Places
Samples:
References:
in Simulation 6(02) February 1966 view details
in Simulation 6(02) February 1966 view details
from the FORTRAN/ALGOL type, though it does utilize FOR-
TRAN formula and logic representations (and actually con-
tains FORTRAN IV as a subset). With the new language, the
user need only describe his problem in "equation-like" form.
The method of solution is automatically provided in conjunction
with the translation from equation form to computer instructions.
In this way the POSE language user can solve difficult computa-
tional problems (like the solution of differential equations)
without requiring a knowledge of numerical methods or the
intricacies of computer subroutine logic. Essentially all clerical
operations now required for FORTRAN programming have
been automated so that the POSE programmer need not be
concerned with these details.
Extract: Introduction
Introduction
Algebra-like programming languages, such as FORTRAN, were originally intended to greatly simplify the creation of computer programs, especially for the novice or occasional user. However, as these languages have been augmented to deal with most computer applications (as in, for example, FORTRAN IV), they, themselves, have become quite complicated and difficult to use.
The main reason that programming remains so difficult is the supposition that the original program must completely describe the method of solution for a problem. The introduction of standard subroutines somewhat alleviates the burden, but the programmer still must actively select the subroutine and supply it with all of its necessary information. This latter activity is often a burdensome clerical task, as are so many other programmer chores, like defining COMMON regions, writing FORMAT statements, and developing intricate control logic.
In contrast, Pose programs for most problems will be very simple. The prime reason for the simplicity is that a Pose program consists of a problem statement in equation form; the "compiler" supplies the method of solution and performs essentially all clerical chores. This concept, wherein the solution method is pre-empted by a "solution compiler," is certainly not satisfactory for all problems, but neither is FORTRAN, ALGOL, or PL/I applicable to all programs. However, most programmers utilize standard numerical methods; hence, for a broad class of problems, the atttomatic selection and intplementation of suitable procedures will be a distinct asset. Thus, the computer will assume another tedious burden previously associated with computer program development.
In addition to automatically providing solution methods, the Pose "compiler" can supply a variety of alternative display procedures in order to better communicate the significance of the solution to the user. The selection of a display mechanism is simply indicated by a verbal description of what is to be displayed, e.g.,
PLOT GRAPH 1 (X, Y. VS. TIME), or PLOT PERSPECTIVE (Z. VS. X, Y) FROM (X1, Y1, Z1). Extract: Problem Statement Language
Problem Statement Language
Since POSE is at, a higher logical level than normal programming languages, POSE includes both FORTRAN- type and symbolic machine languages as logical subsets. In its initial implementation on the IBM System/360 and 1800, it will utilize FORTRAN conventions to express algebraic statements. By inclusion of a suitable "Segment Descriptor" (a heading which describes the function of the program segment), assembly language instructions can also be included. Thus, the use of the extended logical features included in POSE does not preclude the use of any other programming tools.
The extended capabilities included in the initial version of POSE will be:
(1) Solution of simultaneous ordinary differential equations (initial value problems)
(2) Evaluation of multiple integrals
(3) Solution of a transcendental algebraic equation
(4) Solution of a system of linear algebraic equations
(5) Matrix arithmetic
(6) Inversion of square matrices
(7) Simplified data input
(8) Simplified printed output
(9) Two-dimensionM graphical display
(10) Table lookup and Nth-order interpolation
(11) Basic statistical computation
(12) Function evaluation with automatic parameter variation
All of these Pose capabilities will be utilized without the usual organization and planning associated with selec- tion and use of subroutines to accomplish these functions. Extract: Language Philosophy
Language Philosophy
In order to understand the relationship of POSE to other languages, particularly FORTRAN and Assembly Language, it is useful to view Table I as constructed by W. H. Burkhardt
| Absolute Machine Languages (machine level) | No declarative freedom |
| Assembly Languages | No specification of names and locations necessary |
| Procedural Languages (FORTRAN, ALGOL etc.) | No detailed machine commands necessary |
| Problem-oriented Languages | Language elements from problem but command structure procedural |
| Specification Languages, Augmented by Semantics (e.g., Analog-hybrid Simulators) | Description of the relations in problem, freedom of procedure |
| Declarative Languages (problem level) | Description of the problem, freedom of procedure and solution |
POSE, unlike those language types described in the table, may utilize program segments at essentially all levels of the hierarchal scale; thus POSE may be designated as a Polymorphic Language.
POSE can be (and very often will be) used as a general-purpose Declarative Language (by omitting the CALCULATION SEQUENCE segment). However, when sequence of calculation is essential for the proper posing of a problem, it may be explicitly controlled by EXECUTE statements which initiate particular program segments. Within a program segment (except those which include EXECUTE statements or explicitly indicate Procedural or Assembly language.), the order in which statements are written not have a bearing on the solution of the problem. This Independence of sequence is designed to be consistent, with normal mathematical conventions used to describe a problem.
Though POSE problem description statenmnts are, in general, written at the procedural (FORTRAN) Language level, no restrictions are imposed (for machine independance, language purity, or any other theoretical considerations) on the language which a user may employ to best describe his problem. He may intermix POSE code with FORTRAN logic, and even employ assembly language if that seems most appropriate. The prime for this flexible polymorphic form of POSE is the desire to make it universally applicable to a broad range of engineering and scientific applications, including the reduction of experimental and flight test data. In addition, POSE is designed to be applicable to large calculations which are entered into the computer complex by conventional means (punched cards), and small calculations which can be entered directly by remote consoles.
Thus, the most sophisticated components of POSE comprise a general-purpose Declarative Language designed for engineering and scientific application. By inclusion of the CALCULATION SEQUENCE segment to provide some gross control of the calculation procedure, or by utilizing lower level programming languages at the user's discretion, the desired balance between problem-solving ease and solution control can be achieved for each user and each application. Extract: Implementation Considerations
Implementation Considerations
Superficial appraisal would indicate that the development of a "solution compiler" to interpret a Polymorphic Language like POSE would be a substantial task, possibly exceeding the effort required to create a FORTRAN, ALGOL, or PL/I compiler. However, an initial version of the cap ability described herein is expected to be implemented for the IBM System/360 and IBM 1800 with less than a one man-year effort for each computer.
There are two basic reasons for this optimistic estimate:
(1) POSE will utilize FORTRAN as both a source language for algebraic problem statements and for the "object" program emanating from the Pose language processor; thus most of the conventional compiler functions can be utilized without re-creation.
(2) Although POSE has an apparent unique capability to require only a problem statement rather than an explicitly programmed solution, many essentially similar programming languages have been implemented and tested. Their general applicability to provide problem-to- program translation through a variety of standardized solution techniques has not heretofore been recognized. This concept of a "solution compiler" currently exists in nascent form in that digital computing stepchild, the continuous systems simulation language, (e.g., MIDAS, PACTOLUS).
In considering the form that EASL, an Aerospace-developed continuous systems simulation language, should assume on the IBM 360, it became clear that, by simple generalization, the simulation language would become the POSE language, a useful tool for a very broad class of digital computer users. Continuous systems simulation languages have been primarily oriented towards former analog computer users. Hence, they utilize such concepts as "integrators," '
Schlesinger and Sashkin [28, 37] also reported in 1966 the development of EASL (Engineering Analysis and Simulation Language) for the IBM 7094 computer. It allows intermixing with FORTRAN statements. The EASL is implemented with two consoles: a CRT console for on-line display and a typewriter/plotter console for on-line plotting and data entry.
in [ACM] CACM 10(05) (May 1967). view details
in ACM Symposium on "Interactive Systems for Experimental Applied Mathematics", editors Klerer and Reinfelds, Washington, D.C., August 1967 view details
Resources
- EASL Console
