SLANG(ID:470/sla008)Simulation languageDigital simulation language from TRW, charactersed by naturalness and ease of use. Interesting feature is a universal closure - REJOIN for END IF LOOP etc. References: SLANG is a mathematical problem modeling and solution language. It is one of several languages in the programming subsystem of the Computer User Executive (CUE) System developed by TRW Systems. SLANG is both a procedural and a command language designed primarily for the "casual" user. Consequently, much attention was paid to programming ease, "natural" syntax rules, readability, and debugging ease. On the other hand, SLANG is designed to permit the solution of very sophisticated mathematical problems, characterized by iteratlve solution methods. Its translated object code therefore contains complex numerical solution logic in addition to the object code of its procedural syntax. The solution logic is generated by the presence of language commands such as "SOLVE" for the solution of simultaneous nonlinear algebraic equations; and "MINIMIZE" for finding the minimum of a function of several variables. For iterative methods, like both of the above, the compiled code will compute partial derivatives from the procedural formulas, of the objective function and/or constraints with respect to designated independent variables, as needed by the solution algorithm. In addition to the above features, SLANG is user-extenslble. The user may program macro operators using a SLANG macro facility; or he may program relocatable SLANG or Fortran subroutines, and may define calling statement syntax for either macros or subroutines using a syntax macro processor. Thus SLANG may be augmented and tailored to fit individual user needs. Extract: Language Philosophy Language Philosophy A major indication of the simplicity and "naturalness" of a programming language is its readability. To be easily read, it must conform largely to the structural rules of ordinary written English. First of all, there is a single main thought stream of written text from which all digressions are temporary and which always resumes at a point immediately subse~u~ntto the digression. Footnotes, and asides, have this character in English, as subroutines and macros do in programming languages. Secondly, in English there is no counterpart to the direct (non-return) transfer; consequently, its extensive use in programming language leads to reading difficulty. SLANG syntax is designed so that direct transfers are largely unnecessary, although transfer statements are provided. In keeping with the pattern of digression with subsequent resumption, SLANG statements which "open" the main thought stream (e.g. conditional statements and cycling statements) have associated "closing" keywords, such as REJOIN, which resume it again. SLANG statements are free field, allowing ample use of indentation; and SLANG operators are free of unnecessary delimiters; but blanks, as in English, may have significance as separators. The use of subordination through indentation and the use of statement keywords as group lahels permits complex logical constructions to be easily coded or read. Extract: Problem Solving Features Problem Solving Features Problem Model Structure Mathematical models, in general, are composed of a set of independent variables, a set of dependent variables, and the functions, explicit or implicit, that relate them. Problems may be characterized as direct or indirect, pertaining to Whether the unknowns of the problem are dependent variables or independent variables, respectively. The correspondence may be extended to solution methods, which involve direct computations or iterative (indirect) computations. Of course, compound models may be a mixture of direct and indirect problems, thus calling for a mixture of direct and iterative solution computations. Procedural languages generally do not provide built-in methods for solving indirect problems, or even complex direct problems. They only provide procedural statements that can be used to construct algorithms for solving such problems. Direct Methods Procedural languages do provide built-in features for treating the simplest direct problems: automatic parsing for arithmetic replacement formulas; function s~oprograms for single-unknown multi-formula functions; and procedure subprogr~s for multi-unknown, multi-formula functions. All of these features serve to simplify the solution of direct problems because they implicitly handle the bothersome "mechanical" tasks which the user takes for granted, and they permit large problems to be treated as a group of individual smaller problems. However, for direct problems which involve secondary computations (e.g. numerical integration), procedural languages provide no built-in methods because such methods require intervening execution of selected parts of a problem model, and therefore must control the flow of the program. This has given rise to a number of simulation languages such as DSL/90, CSSL, and CSMP which are structurally compatible with the solution process of numerical integration in addition to having procedural capabilities. Iterative Methods Strictly procedural languages offer little capability for indirect problem solving because not only do such problems require secondary computations, i.e. partial derivatives, but to be foolproof such quantities should be computed from exact rather than approximate formulas. This requires that the language processor derive the secondary computation logic from the structure of the algebraic formulas in the model. The simplest class of such problems, although far from simple, is the solution of a determined set of nonlinear algebraic equations: gl (XI, X 2 ... X n) = 0 g2 (XI, X 2 ... Xn) = 0 gn (XI' X2 ... X n) = 0 Such a system is said to have zero degrees of freedom because the number of unknowns X (independent variables) equals the number of equality constraints g (dependent variables). [...] Problems which have more unknowns than equality constraints, i.e. problems with one or more degrees of freedom are optimization problems, because no longer are there a finite number of solutions; and meaningful solutions can only be obtained by imposing criteria which fix the values of the independent variables as well as satisfy the constraints. [...] A cormmon requirement for a general capability for optimization and nonlinear equation solving is a mechanism for computing partial derivatives with respect to designated independent variables. Such a mechanism is a primary feature of SLANG. It permits complex indirect problems to be solved with equivalent ease of numerical integration. Extract: Command Structures Command Structures SLANG's built-in problem solving capabilities are implemented by the user through statement groups called command structures. Statements which make up command structures are of three types: commands, command specifications and command declarations. A command structure is a specific sequence of such statements which specifies and executes the solution of a complete mathematical problem? Composite SLANG programs may therefore contain several command structures, one for each complex problem in the makeup of the overall program. Command specifications are used to select and initialize numerical algorithms from the SLANG method library. Currently SLANG contains three specifications, INTEGRATION, OPTIMIZATION and CONTROLS ? Commands are SLANG statements that invoke the execution of algorithms which have been previously selected and initialized by the appropriate specification. The primary SLANG commands are: INTEGRATE, OPTIMIZE, MAXIMIZE, MINIMIZE, STEP OPTIMIZE, STEP MINIMIZE, STEP MAXIMIZE, PARTIALS, FIRST PARTIALS, NO PARTIALS, and SOLVE. Command declarations are used to identify variables that have special significance in a given command structure (e.g. independent variables) ? The primary declarations are INDEPENDENT(S), CONSTRAINT( S), and LAMBDA(S). Associated with every command structure there is a group of formulas which comprise the mathematical problem to be solved ? This group of formulas is called the command-model. It may be coded immediately within the command structure or may reside in SLANG subprograms which are executed within the command structure? in Proceedings of the twenty-fourth ACM national conference August 1969 view details Fourth-order Adams-Moulton integration is used to solve sets of differential equations and the Newton-Raphson method is used to solve sets of implicit algebraic equations. Like CSMP, SLANG is designed to iterate through macro-type statement blocks, but unlike CSMP, SLANG can automatically provide first partials of each constraint variable with respect to each independent variable. The paper describes in detail an application of this language to simulate the propagation of a strong shock wave travelling down a shock tube with discontinuous area change. The model employs nineteen simultaneous equations, seven of which are first-order homogeneous differential equations. Since no statistics were provided on compile times, run times, etc. it is not possible to compare SLANG with other continuous systems simulation languages of the same type. The authors mention syntactic similarities to FORTRAN but do not imply FORTRAN compatibility. in ACM Computing Reviews 11(02) February 1970 view details in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details Extract: Introduction Introduction The simulation of physical systems requires the implementation of a mathematical model characterizing the system under study. In a broad class of physical systems, the basic governing equations are known but the system parameters must be identified using experimental observations of the system. This is the case in such environment- orientated areas as air pollution, water pollution etc. A number of problem-oriented programming languages have been developed to facilitate simulation. For discrete-time systems, GPSS and SIMSCRIPT are widely used. For continuoustime systems characterized by ordinary differential equations, CSSL and CSMP are particularly helpful. PDEL and LEANS have been introduced for distributed parameter systems characterized by partial differential equations. In all of these languages, the mathematical model must be completely specified as they are intended for direct rather than inverse problems. A number of language extensions suitable for parameter identification in lumped (ordinary differential equations) systems have been described in recent years. These include MOBSSL-UAF and SLANG. The present paper describes a major extension of the partial differential equation language PDEL so as to make it useful for the identification of parameters in distributed parameter systems. Extract: PDEL-ID LAnguage Language Facilities There are four major language facilities provided by the implemented PDEL-ID system. They are: 1. System model specification 2. Observation data input 3. Parameter identification 4. Print-out control The system model specification facility, which for the most part is the same as in PDEL, enables the user to describe the distributed parameter system model to the computer. This is done through the use of the dimension, equation, parameter assignment, geometry, boundary condition and initial condition statements. The syntax of all these statements had already been described by Cardenas and Karplus. In addition, for system identification problems, unknown parameter identifiers, defined in Section 4.2.1, are used to specify those system parameters which have to be identified. The print-out control facility allows the user to specify interval sizes in space and time for both the numerical solution print-outs and solution plots. This facility has already been designed and implemented in PDEL. 3.1 Observation Data Input Facility For a simulation language designed for system identification such as PDEL-ID, the design of facility to handle observation data input deserves careful considerations. In system identification problems involving distributed parameter systems, the observation data used for identification contain the following attributes: 1. Field locations of observation points. 2. Measurement values of the variables observed. 3. Time corresponding to each measurement value. 4. Weight of the measurement value (sometimes). The observation data input facility is designed to provide flexible and simple data attribute specification with clear and complete problem documentation. The syntax of the statements in this facility is described in Section 4.1. 3.2 Parameter Identification Facility Since PDEL-ID is designed for distributed parameter system identification, the facility for parameter identification forms the heart of the entire language. The design of such facility is based on the following characteristics: 1. The design of the facility is aimed at slmple problem specification, programming ease, and natural syntax. 2. The use of the facility does not require detailed knowledge of the identification process involved. 3. Several identification schemes are available so that the most suitable one can be used. (Two are available at present, the quasilinearizatlon technique and the Fletcher-Powell technique). 4. The identification schemes are implemented in modular form and the language statements are completely compatible with all the identification modules. 5. Default conditions are available. If some necessary information is not specified by the user, some predetermined information is assumed. 6. The sensitivity of the criterion function value with respect to each of the parameters to be identified is calculated to give an indication of the reliability of the identlfied parameter value. Language statements are divided into identification initialization and identification control statements. The syntax of these statements are given in Section 4.2. in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details |