AMTRAN 70(ID:7104/amt002)

Automatic Mathematical Translator 


Enhanced version of AMTRAN


Related languages
AMTRAN => AMTRAN 70   Evolution of
Church typed-lambda calculus => AMTRAN 70   Incorporated some features of
AMTRAN 70 => SIGMA 76   Incorporated some features of

References:
  • Eskelson, N., Kopetz, H., "Program Logic of the AMTRAN Software for the IBM 1130" AMTRAN Report 1970-9 Computer Center, University of Georgia (1970). view details
  • Reinfelds, J. "AMTRAN: An Interactive Computing System", pp537- 542 view details Extract: COMPARISON WITH OTHER HIGH LEVEL LANGUAGES
    COMPARISON WITH OTHER HIGH LEVEL LANGUAGES
    A comparative study between AMTRAN and other
    high level languages has to be divided into two parts. Only language features can be compared with batch mode languages, whereas the whole AMTRAN- system can be taken into account for a comparison with other interactive systems.
    Batch mode languages
    Most likely, PL/1, ALGOL, or FORTRAN would be used to solve mathematical, technical or scientific problems in batch mode. A comparison with AMTRAN is not really feasible as the basic philosophy and design principles of batch mode languages are completely different from AMTRAN.
    Since language development goes more and more in the direction of powerful general purpose languages, it becomes more and more difficult, time consuming, and cumbersome for the nonprogrammer to make the first step towards use of a computer. But even for the experienced user, the three languages mentioned above do not provide the convenience and facilities in programming that AMTRAN does. They need type and dimension declarations; the flexibility in changing types and dimensions at run time is lacking; and they do not have AMTRAN's array handling capabilities.
    PL/1 with its default philosophy, its various types of storage allocation, and certain automatic array arithmetic features is close to AMTRAN's facilities and philosophy of programming convenience. On the other hand, it is inconvenient for the user to keep track of storage allocation  problems in writing recursive or re-entrant programs or in using arrays with computed origin.
    PL/1 is truly a general purpose programming language. It is designed for programming needs in science, engineering, data management, and business. AMTRAN, on the other hand, is a special purpose programming language for mathematical, scientific, and technical applications and has not been designed to compete in general with a language like PL/1. It is not intended to handle extensive data; therefore, it does not need powerful I/O-capabilities and sophisticated formatting facilities. But it can compete or even perform better within the limits of its special purpose.
    Interactive systems
    An interactive console system fills the gap between a desk top calculator and conventional batch mode
    computer programming. On one hard, it has to give immediate answers to simple request on the other hand,  it has to provide powerful programming capabilities.
    A milestone in the development of interactive systems was the Culler-Fried-Systen . which strongly influenced the early AMTRAN development. Prof. Culler's system represents a highly powerful multi-console system. A disadvantage is that it does not stay close to the mathematical notation, and it is not simple and easy to learn.
    CPS is a conversational subset of PL/1. It has a calculator mode and a program mode and is a useful conversational system although it does not have AMTRAN's flexibility and power in a ray and function handling.
    Iverson's language APL (A Programming Language) is a more formal approach to application programming. It is particularly useful for classical mathematical applications, and it has been implemented as a powerful interactive time-sharing system. The language has features such as array arithmetic, programming capabilities, and a large set of primitive operators including matrix handling operators. An extenstive set of special symbols is used instead of keywords. Thus, a special typewriter is necessary. The proponents of APL claim that its source code is more efficient per statement than that of any other programming language. On the other hand, it is less readable. One has to learn special symbols instead of using mnemonics. For example, the quad [] in APL is less informative as an output operator than the TYPE in AMTRAN.
    Major disadvantages are that APL does not follow classical mathematical notation, there is no hierarchy among operators, and the order of execution of statements is from right to left. This meat the mathematician and scientific nonprogrammer must convert his formulas, written in normal textbook format, into the APL-notation, and the programmer experienced in any other language is even more confused. APL is a language which requires both care and training for simple applications.

          in [AFIPS] Proceedings of the 1970 Fall Joint Computer Conference FJCC 37 view details
  • Kopetz, Hermann "On the implementation of an interactive system on a small computer" pp2-4 view details DOI Extract: Introduction
    The characteristics of a problem which is likely to be encountered in the field of problem solving
    + compute bound
    + small amount of data handling
    somehow relate to the characteristics of the small computer
    + powerful central processing unit
    + small core storage
    The main difficulty lies in the specification and execution of the sometimes complex computational algorithms within the limited amount of core storage without accessing the secondary storage device too often.
    A compact specification of an algorithm can be achieved by a set of powerful problem oriented language operators . For example, the mathematical expression (Simpson Integral)


    can be calculated in two AMTRAN statements:

    since the integration operator is part of the basic AMTRAN system. Similar examples can be given for the powerful SYMBOL operator and many other language features. Such a user oriented source level language makes it possible to express complex computational algorithms within a few lines of source code and correspondingly in a small number of core storage locations. The implementation of an interactive system on a small computer is much more critical if the source language requires a large number of statements (and core storage locations) to express rather common user algorithms.
    The second part, the execution of the complex algorithms within the limited amount of core storage is solved by a problem oriented system design. Such a design is only possible in a dedicated system, which does not have to take account of all requirements which are part of a general purpose operating system.
    The implementation of the AMTRAN language on the IBM 1130 computer is disc oriented.
    All input output modules and the disc organization are specifically designed for optimum efficiency in a dedicated timesharing environment. Only a part of the system programs reside in main storage at any one time. The remaining programs are in core image format on the Fixed Area of the system disc. They are organized in a number of overlays each one of which fills exactly one cylinder. No effort has been made to create device independent data sets since the additional overhead cannot be justified on such a small system . All system programs are reentrant and it is therefore not necessary to write them back out on the disc. All user dependent information is in the particular user area.

    The translation of the source code to an Intermediate object code is done in one pass . This intermediate object code, a polish representation of the source code, consists of a series of calls to the appropriate execution routines and the associated parameters . The execution routines perform the actual operations, the program linkage, the run time checks and the data management . The user area is completely dynamic . There is no fixed boundary between the program space, data space, the namelist, the translation stack, the execution stack etc.

    It is therefore possible to write recursive programs in AMTRAN.

    The structure of the translator has been influenced by the language definition [3] which makes a clear distinction between the structural and semantic characteristics associated with each language element . Since AMTRAN does not require dimension or type declaration statements, the checks on the dimension and type of a variable are not performed at translation time . Many different high level operators belong to the same syntactic class so that the same translation mechanism can be used for a number of them.

    Because of the limited amount of main memory it is not possible to have more than one user area in core at a given time . This constraint has affected the system layout to a considerable degree . To gain optimum run time efficiency, the system can adapt to the characteristics of the particular user problem . This has been achieved by an overlay structure where each overlay is tailored to a specific class of user operations . For example, the modules for the logical operators and the conditional operators will be in the same overlay, the trigonometric and the basic arithmetic functions will be together etc. Many commonly used modules will be in more than one overlay . The composition of the overlays, which can be changed easily, has been determined by run time observations over a large number of user programs . The same is also true for the sequence of overlays on the disc to minimize excessive arm movements.

    Such an approach will not succeed in a system, where several user areas reside in core at the same time because, in the general case, the problems being solved in them will not fall into the same category . A considerably larger number of core resident execution modules would be needed to get a comparable runtime efficiency for such a system.

    Furthermore, if the services of a general purpose operating system must be used to guarantee overall system integrity, a new situation arises. The operating system standards have been determined by a completely different set of objectives (e .g . device independence, expandability, data management) and an optimization of the timesharing system within these standards will only lead to a suboptimal system . Although the gain in computing power according to Grosch's [4] law will definitely outweigh the increased overhead, the chances of system breakdowns because of increased complexity are increased . A dedicated system on a large computer is in many cases economically not feasible since, as Auerbach [6] states, only two to three timesharing terminals are used in a typical user installation.
          in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
  • Kratky, Gerhard "The Definition of AMTRAN" view details Extract: Introduction
    Introduction
    AMTRAN is an interactive, mathematically oriented computer system consisting of one or more remote terminals with a special function keyboard and immediate output of solutions in numerical or graphical form via storage scopes.It is designed especially for engineers and scientists who have no previous acquaintance with computers hut want to solve their numerical problems as quickly and efficiently as possible . AMTRAN allows simple problems to be solved easily and also permits the construction of complicated algorithms.
    This report gives a concise, semantically-oriented definition of the AMTRAN-language; it is not intended to replace a manual. It should instead be supplementary to a manual and is primarily thought of as an aid for the compiler writer and as an exhaustive and exact definition of the language and its unifying concepts.
    A general method of definition (applicable for any mathematically-oriented computer language) has been developed with the following aim: the systematization and formalization should cover a much larger part of the language than 'syntax'-definitions or the definition by BNF-notation (Backus Normal Form; ALGOL 60 Report). This is achieved by systematizing a large part of ' semantics ' in formalizing notions like 'type', 'range', 'sign', 'dimension' of numerical quantities and 'binding power' of mathematical operators.

          in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
  • Reinfelds, Juris "A concept by concept description of the AMTRAN language" view details Extract: Introduction
    Introduction
    The purpose of this paper is to describe the state of development of the AMTRAN language as it exists at this time. The description emphasizes the basic concepts on which the language design is based. Some of these concepts are already well developed and complete, others need further development indicating that AMTRAN has not yet achieved a completed final form . Most of the concepts discussed are implemented on the 1130 AMTRAN system, but some are not implemented because our NSF grant expired before this implementation could be completed.
    These concepts and further extensions including the full n-dimensional array arithmetic will be included in the next implementation which is presently in progress at CERN, Geneva, Switzerland, on a CDC 6600 computer.
    The main aim of AMTRAN is to exploit the general n-dimensional rectangular array as a basic data structure, using operators derived from concepts familiar to a numerical analyst. All general purpose programming languages provide array handling through explicitly programmed loops. The emphasis of AMTRAN (as well as APL, Culler-Fried and Klerer-May systems) is to make such component handling loops implicit and invisible to the user by providing operators which operate on the whole array or, in other words, regard the array, rather than a single number, as a basic data type of the language.

    Languages in general and AMTRAN in particular have at times claimed to be easy to learn and easy to use. In many cases such claims are heavily tainted with emotions and a lack of knowledge and understanding of other languages. The purpose of this paper is to establish a rational base upon which AMTRAN's claim to simplicity and learnability may be founded.
    It seems reasonable to assume that some measure of the ease with which a casual user can learn a computer language is given by the number of new concepts he has to learn before he can solve his particular problem with this language. Therefore, this paper describes the AMTRAN language through the concepts and rules an average user has to learn before he can solve his problems with it.
    The average user is a scientist who has no background in computer science, but has some knowledge of numerical analysis or statistics. In other words, he should know the algorithms required to solve his problem. The average user will also know some Fortran because almost every science student of today is exposed to at least a one quarter introductory course on computing.

    A concept is a conventional concept if it may be assumed known to the average user as defined above. More subtly, four broad groups of concepts may be distinguished:
    (i) entirely conventional concepts, as for example -+- denotes addition in almost all computer languages in exactly the same way as addition is conventionally known in high school algebra and arithmetic.
    (ii) partly conventional concepts, as for example * or / for multiplication or division which are largely conventional but contain a few clarifications and extensions such as a definition of A/B/C for linearly written expressions, the use of * for multiplication sign introduced by FORTRAN, the handling of division by zero, and so on.
    (iii) entire new concepts, as for example the right to left rule of APL or the block structure of Algol.
    (iv) disguised conventional concepts, as for example the declarations of FORTRAN. They appear as a new concept because they are introduced as 'non-executable statements which contain information to the compiler'.
    They would appear conventional if they were interpreted as executable statements which create a data structure in the computer so that this data structure can later be filled with numbers or characters, manipulated and used in calculations . This interpretation would be very close to the conventional interpretation of the numerical representation of a mathematical function.
    AMTRAN is an operator-operand language. All actions which are to be performed are expressed by operators which are the dynamic elements of the language . All actions are performed on operands which are the static elements of the language . Only the number of arguments assigned to each operator may be deduced unambiguously from the syntax of the source code.
    The type and dimension of each operand is checked interpretatively at run time by the execution routines of the operators . By executing arrays as whole entities, interpretation is done once for each array and efficiency is improved by a factor equal to the reciprocal of the number of elements in the array.
    This paper refers to the University of Georgia implementation of AMTRAN on the IBM 1130 computer . This implementation is similar to the Huntsville implementation for the IBM 1130, the Datacraft and PDP-9 computers.

    Extract: Rules
    2.0 Rules
    The rules of a language give the user general guidance on how to use the language. The rules should be simple, clear, concise and general, like the axioms of a mathematical theory . They should avoid special cases and exceptions and apply directly to as many situations as possible.
    Our inability to find such rules for most computer languages results in large user's manuals containing a compendium of special cases and  exceptions to whatever rules are written down at all. Extract: Operand Rule
    2.1 Operand Rule
    Operands are used in three basic situations: assignment, procedural and value generating situations.

    (i) in any value generating situation use any expression which may be constructed from the value generating operators defined in the language.
    Exceptions: none
    Consequences :
    a) a computed GOTO is automatically a part of the GOTO statement of the language, provided that statements are labeled with numerical labels.
    b) logical and relational operators must be regarded as an integral part of the generalized arithmetic as there is no syntactic distinction between Boolean and non-Boolean expressions. (ii) in any assignment situation use any name.

    (ii) in case of assignment to array elements or subarrays the name may be subscripted.
    Exceptions: none
    Consequences:
    a) the new value or program replaces whatever value or program, if any, was previously designated by that name.
    b) no artificial conventions distinguishing type and/or dimension of variables from the lexicographic structure of their names.

    (iii) in any procedural situation use any complete statement of the language. For example any complete statement (including an IF statement itself) may appear between THEN and ELSE or between ELSE and FI of any IF statement.
    Exceptions :
    Presently programs cannot be defined or edited by running programs. It is still a controversial issue whether self-modification of programs is desirable or not.
    Consequences:
    Powerful flexibility through nesting of statements within each other.

    Extract: Operator Rules
    2.2 Operator Rules
    (i) expressions are evaluated from left to right with value generating operators obeying conventional priorities, but parenthesis may be used for easier reading or whenever a doubt exists as to what is meant by conventional priorities.
    Exception:
    Linear writing of expressions causes many unconventional situations where parenthesis may be needed for clarity as for example in A / B * C
    (ii) arguments of all prefix operators should be placed in parenthesis. More than one argument constitutes an argument list where adjacent items are separated by commas.
    (iii) operators are denoted by mnemonic keywords or conventional symbols (when such symbols exist) or single key-pushes on a special keyboard (when such a keyboard is available).
    Extract: Blank Space Rule
    2.3 Blank Space Rule
    As in English, a blank space is regarded as a delimiter. Two or more adjacent blank spaces are equivalent to a single blank space everywhere except in the definition of a string array.
    Extract: Humanizing Redundancy Rule
    2.4 Humanizing Redundancy Rule
    If syntactic ambiguity can be avoided, some of the above rules may be relaxed to permit redundant simplified notation in addition to the notation required by the rule.
    For example: the requirement that arguments of prefix operators must be in parenthesis may be omitted if the arguments are simple identifiers or single argument functions . Hence, it is syntactically unambiguous to permit both forms sin(cos(x)) - sin cos x

          in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
  • Reinfelds, Juris "AMTRAN 70" pp370-375 view details
          in Freiman, C. V. et al (Ed) Information Processing 71, Proceedings of IFIP Congress 71, Ljubljana, Yugoslavia, August 23-28, 1971 view details
  • Reinfelds, Juris "Some applications of AMTRAN" pp60-90 view details DOI Extract: Introduction
    Introduction
    This paper contains a small collection of AMTRAN programs. These routines are typical of what an average user may construct for himself. They were constructed by the early users of the 1130 AMTRAN to solve their immediate problems and to test the system. Comprehensive application packages for general purpose problem solving have not yet been developed for AMTRAN.
          in SIGPLAN Notices 6(11) November 1971 Special issue on AMTRAN (Automatic Mathematical TRANslation) view details
  • Teague, R. R. review of J. Reinfelds 1972 view details Abstract: This paper provides a progress report on the development of the AMTRAN language first described at the 1966 ACM National Conference
    The language is a terminal-oriented interactive language using the standard mathematical symbols and operators (which distinguishes it from APL). It also allows userdefined operators (distinguishing it from BASIC).

    In Section 2 of the paper the author gives a brief yet thorough synopsis of the language syntax and some of its operational characteristics. One interesting feature is the Teach mode of operation, which allows a user to obtain a description of any of the system operators while programming at the terminal. Section 3 deals with the implementations of A~aTuAN on the IBM 1130; the final section gives several examples of the use of AMTRAK for differing problems.

    The paper is well written, and is easy to follow as a result of the extensive use of examples. It has whetted this reviewer's interest in discovering more about this conversational language.
          in ACM Computing Reviews 14(05) May 1973 view details