| Interactive programming and automated mathematics | | BIBA | Full-Text | 3-10 | |
| Melvin Klerer | |||
| The theme of these symposium proceedings is Interactive Systems for Experimental Applied Mathematics. Certainly, there can be little confusion about the basic meaning or broad fundamentals of applied mathematics. However, questions as to the value of the experimental approach toward mathematics are an entirely different matter. The present state-of-the-art is so scant in empirical or theoretical guidelines that this approach must be acknowledged as an expression of faith that a computer, used to explore ill-defined mathematical constructs and problems, might yield powerful insights and a fruitful methodology. The term interactive is difficult to define and I cannot pretend that I fully understand the relevance of the term as applied to some specific systems. However, in some sense, we would suppose that what we mean is close to the definition used by the physicist. When two effects interact, they do so in a nonseparable and usually nonlinear way. Usually, the effect of the interaction is that the whole is not simply equal to the sum of its parts, and that the characteristics of the interacted system can be surprisingly different from the qualities of its constituent parts. Therefore, in the man-machine interaction, we would expect more than in the old process of inputting a well-formulated set of directions with the machine performing in its capacity as an idiot savant. Obviously we can expect that any serious attempt at man-machine interaction will involve on-line response. However, I would not entirely exclude the possibility that significant interaction can occur off-line. | |||
| On the user's point of view | | BIBA | Full-Text | 11-21 | |
| Burton D. Fried | |||
| In this discussion, I shall try to identify those general criteria for interactive on-line systems which seem most important for the experimental solution of mathematical problems. To illustrate some of these, I shall refer to Professor Glen Culler's on-line system [1, 3], which has been in operation at the University of California at Santa Barbara since 1966. While it is far from an ideal system, I believe that it still ranks first in terms of the number of real problems (of at least moderate difficulty) which have actually been solved, by a variety of users, with the aid of this system or one of its earlier versions. Its strengths and weaknesses have, therefore, some general relevance to a discussion of on-line systems for experimental applied mathematics. | |||
| The APL\360 terminal system | | BIBA | Full-Text | 22-37 | |
| A. D. Falkoff; K. E. Iverson | |||
| APL\360 is an experimental interactive system, programmed for IBM System/360 computers, which uses typewriter terminals connected to the central machine by telephone lines for both input and output. The basis of the system is APL [1-4], a truly machine-free programming language which leans heavily on mathematical notions, but does not slavishly follow classical mathematical notation. Correspondingly, the running system, which is completely interpretive, makes no significant concessions to implementation problems. | |||
| The Maniac II system | | BIBA | Full-Text | 38-43 | |
| Roger Lazarus; Mark Wells; John, Jr. Wooten | |||
| The operating system to be described in this paper serves the Maniac II computer and about 40 users. Maniac II is a research computer and undergoes more or less continual modification and improvement. In its eleven-year life, it has grown in speed from 10,000 instructions per second to 100,000, in vocabulary from 80 instructions to about 300, and in memory size from 12,000 words to 80,000 (changing from half- to full-word instructions in the process). It runs in an open shop. It is in operation about 130 hours a week with only about 50 hours being handled by professional machine operators. At least 8 hours a week are devoted to new construction. On-line input/output equipment consists of console typewriter, scope display, paper tape reader and punch, card reader, line printer, and magnetic tapes. Off-line there are two magnetic tape driven Cal-Comp plotters, an IBM 047 keypunch, and the modified Flexowriters referred to below. | |||
| AMTRAN: automatic mathematical translation | | BIBA | Full-Text | 44-66 | |
| Robert N. Seitz; Lawrence H. Wood; Charles A. Ely | |||
| AMTRAN is a time-sharing remote-terminal computer system ultimately intended
to permit scientists and engineers to "converse" directly with a computer in a
"natural" mathematical language. Its current objectives entail attainment of
the following goals:
a. "automatic" mathematical problem-solving, b. high-speed, on-line, scientific programming, c. a macro-compiler and operating system, and d. the development of low-cost, $5,000-15,000, graphic display terminals. | |||
| Structure of a language for a numerical analysis problem solving system | | BIBA | Full-Text | 67-78 | |
| Lawrence R. Symes; Roger V. Roman | |||
| The Numerical Analysis Problem Solving System (NAPSS) project has been undertaken at Purdue University to design and construct an interactive system for solving numerical problems [1]. The system is designed to accept input in a language which is very close to natural mathematical notation, and also to provide for the solution of problems without requiring specially trained programmers and numerical analysts. | |||
| REDUCE: a user-oriented interactive system for algebraic simplification | | BIBA | Full-Text | 79-90 | |
| Anthony C. Hearn | |||
| Many of the day-to-day problems which confront applied mathematicians involve extensive algebraic or nonnumerical calculation. Such problems may range from the evaluation of analytical solutions to complicated differential or integral equations on the one hand, to the calculation of coefficients in a power series expansion or the computation of the derivative of a complicated function on the other. The difference between these two classes of problems is obvious; in the former case, no straightforward algorithm exists which will guarantee a solution, and indeed, an analytic form for the solution may not even exist. On the other hand, algorithms do exist for the solution of problems such as series expansion and differentiation, and therefore a correct answer may always be found provided that the researcher possesses sufficient time, perseverance, and accuracy to carry the more complicated problems through free of error. Many examples of this type of problem may be found in physics and engineering. Calculations of general relativistic effects in planetary motion, structural design calculations, and many of the calculations associated with elementary particle physics experiments at high energy accelerators, to name a few, may demand many man-months or even years of work before a useful and error free answer can be found, even though the operations involved are quite straightforward. | |||
| Two analyst-oriented computer languages: EASL, POSE | | BIBA | Full-Text | 91-96 | |
| Stewart I. Schlesinger; Lawrence Sashkin; Kenneth C. Reed | |||
| For approximately three and one-half years a continuous modest-level effort has been maintained at Aerospace Corporation to support the development of analyst-oriented computer languages which could be used for both off-line and interactive applications. Initially, this effort produced a block-oriented macro language called EASL (Engineering Analysis and Simulation Language) [1]. | |||
| VENUS: a small interactive nonprocedural language | | BIBA | Full-Text | 97-100 | |
| Howard F. Matthews | |||
| For this paper, the subtitle terms are defined as follows:
INTERACTIVE: The language processor and the user are engaged in constant dialogue throughout the solution process. NONPROCEDURAL: The input to the processor consists of a problem definition and a request for the solution, rather than a solution procedure. | |||
| AL: an artificial language | | BIBA | Full-Text | 101-105 | |
| Gerald W. Bradley | |||
| This paper presents the original design specifications for an interactive interpretive language. The initial stimulus for designing an extended language was developed from experiences gained in designing and implementing the Pitt Interpretive Language (PIL). The language gains power over many other algebraic languages by allowing the use of five classes of data. | |||
| Active language I | | BIBA | Full-Text | 106-137 | |
| Rene De Vogelaere | |||
| From the user's point of view, there are mainly three ways in which a computer can appear to react to his requests: program by program, line by line, and character by character. In the earlier computers the reaction was essentially program by program unless the user was working at the console. With the advent of time-sharing, besides the program by program reaction, both line by line and character by character reactions become possible. Many languages have already been developed which are suitable for either line by line and/or character by character requests. JOSS, developed at RAND, and its offspring (such as CAL developed in Berkeley) react essentially line by line. The Culler -- Fried language on the other hand reacts character by character. | |||
| The engineering assistant: design of a symbol manipulation system | | BIBA | Full-Text | 138-154 | |
| Edgar H. Sibley | |||
| This article is intended to describe the design of a working interactive symbol manipulation system, but the reasons for a given action and the implications of it are common to the design of other languages. This introduction therefore formulates the questions that must be asked in the design of such a system, discusses possible alternatives, and suggests the effects of the alternatives. | |||
| CHARYBDIS: a LISP program to display mathematical expressions on typewriter-like devices | | BIBA | Full-Text | 155-163 | |
| Jonathan K. Millen | |||
| CHARYBDIS (from CHARacter-composed sYmBolic Display) is a LISP program to display mathematical expressions on typewriter-like devices such as line printers, teletypes, and scopes which display lines of characters, as well as typewriters. It was written as part of the output interface for MATHLAB [1]. | |||
| Coherent programming in the Lincoln Reckoner | | BIBA | Full-Text | 167-177 | |
| Raymond A. Wiesen; Douwe B. Yntema; James W. Forgie; Arthur N. Stowe | |||
| "Coherent programming" refers to a set of conventions and techniques that we believe have the power to shape the growth of a library of programs, so that a user may draw upon them freely and with minimal concern about the details of their compatibility. The purpose of this paper is to explain the concept of coherence, and to show how it has been applied in the Lincoln Reckoner, an on-line system that provides computational assistance to scientists and engineers. The external specifications of the Reckoner, which have been presented elsewhere [1], will not be discussed here. Rather, this paper will concentrate on some of the "architectural" considerations in the design of user-oriented on-line systems. | |||
| Algebraic manipulation on computers for scientists and engineers | | BIBA | Full-Text | 178 | |
| Krzysztof S. Frankowski; C. Duane Zimmerman | |||
| A system for algebraic manipulations using the TYPE OTHER feature of Control Data's F-63 has been developed. The TYPE OTHER feature enables the user to perform algebraic operations without altering the existing FORTRAN while retaining the ability to write statements in the simple FORTRAN language. | |||
| An interactive console operating as background in a large computer system | | BIBA | Full-Text | 179-182 | |
| S. Schlesinger; L. Sashkin; C. Aumann | |||
| In order to fill the gap between small desktop calculators and conventional computer programming, an interactive console system has been developed to permit engineers and mathematicians to solve small scale problems with a simple algebra-like language, EASY (Elementary Algebraic Solutions for You). In order to achieve effective operation at low cost, the consoles (IBM 2260) are supported as a low level background function on an IBM 360 Model 40 computer Attached Support Processor (ASP), which is simultaneously supplying data processing capability to support multiple printers, plotters, card readers and punches, auxiliary storage devices, and the monitoring and job scheduling for an attached IBM 360 Model 65 computer (Fig. 1). | |||
| Design philosophy for an interactive keyboard terminal | | BIBA | Full-Text | 183-191 | |
| Melvin Klerer; Fred Grossman; Charles H. Amann | |||
| The basic version of the Klerer -- May programming system has been in operation at Columbia University's Hudson Laboratories for nearly four years in an off-line mode and for two years in an on-line mode. This system [1-3] permits programming using normal two-dimensional mathematical expressions and flexible language forms. In the area of scientific applications, such a language approach permits faster total throughput, i.e., less time spent in programming or debugging a specific problem compared to conventional FORTRAN-like languages. It also offers a basic framework for extension into other areas such as the manipulation and editing of two-dimensional mathematical input for automatic typesetting of mathematical text [4]. A typical program segment in this language is illustrated in Fig. 1. More visually complex forms, such as multiple integrals, sums, products, and "IF" conditions are also recognized and compiled. | |||
| A facility for user definition of simple problem oriented languages | | BIBA | Full-Text | 192-195 | |
| D. M. Manelski; H. C. Lefkovits; H. J. Hebert | |||
| Notwithstanding the considerable effort expended on development of computer languages, the great majority of users are restricted to one of the common algebraic languages (ALGOL, FORTRAN, etc.) for problem solving. In the authors' working environment, it is possible to identify professional disciplines where a problem oriented language would be of great utility; however, it is clear that in the absence of computing experience, the definition of a useful POL would be a lengthy trial and error procedure. As an aid in language definition a macro facility has been implemented on the Allen -- Babcock Computing IBM 360/50, whose RUSH system provides a conversational subset of PL/1 [1]. | |||
| Mathematical symbol processing | | BIBA | Full-Text | 196-202 | |
| C. Abraham; T. Pearcey | |||
| Most of the early efforts to write computer programs which perform symbolic mathematical operations were directed toward polynomial manipulation including their differentiation and integration [1, 2]. In 1961, Bernick et al. [3] produced an interpretive routine to provide multiple capabilities for a general class of mathematical expression. More recent programs belonging to the same class are FORMAC [4] and Formula ALGOL, [5] but both suffer various kinds of restrictions. | |||
| LC²: a language for conversational computing | | BIBA | Full-Text | 203-214 | |
| J. G. Mitchell; A. J. Perlis; H. R. Van Zoeren | |||
| The purpose of time-sharing is twofold: to increase the efficiency of the computer system and, while attaining this increase, to permit efficient communication between a programmer and his programs. This communication we may call conversation. Prevailing programming languages like FORTRAN, PL/1, ALGOL, COBOL, etc., are poorly designed for such interactive programming. However, languages like JOSS [1], APL [2], and the to be described LC2 are much more suited to this task. | |||
| AMTRAN: implications of an interactive mathematical computer system for an educational institution | | BIBA | Full-Text | 215-219 | |
| A. V., Jr. Jett | |||
| The advent of computing in a remote-terminal time-sharing context permits the user to interact more directly with the computer in attacking his problem. Moreover, certain standard problems of numerical analysis (e.g., least-squares approximations, locating zeroes of functions, etc.) arise in science and engineering with sufficient frequency to suggest, in view of remote-terminal capability, the development of interactive computer systems to aid in the application of mathematical analysis. Such a system is AMTRAN (for Automatic Mathematical TRANslation), being developed at NASA's Marshall Space Flight Center under the direction of Dr. Robert N. Seitz[1]. | |||
| What is different about AMTRAN? | | BIBA | Full-Text | 220-221 | |
| Richard J. Plocica | |||
| As a programming language, AMTRAN is designed to satisfy two objectives: the reduction of programming cost and effort by at least an order of magnitude, and the provision of a semiautomatic numerical analytical problem solving system. It resembles a blend of FORTRAN and ALGOL but possesses certain additional features. These include the following. | |||
| An object code for interactive applied mathematical programming | | BIBA | Full-Text | 222-224 | |
| Kenneth Lock | |||
| We can consider interactive applied mathematics programming to be the teaming of a man and a machine to solve some problems in applied mathematics. The solution of the problem may in general consist of steps of operations upon data constructs which initially represented the problem description. The sequence of operations constitutes the program. In interactive programming, the sequence of operations is often performed alternately by the man and the machine, i.e., each member of the team does the part that he or it is good for. The importance of a programming language that can be used conveniently by man and machine alike to address the elements in the problem area is beyond dispute. Conveniences to the man are the naturalness and expressiveness possible in the language, while the convenience to the machine lies in the efficiency with which statements in the language may be interpreted. A programming language is chosen to strike an appropriate balance. This paper explores the machine architecture by describing the design of an object code which forms the internal representation of the elements in the programming language. The design is such that a PL/1 based language which is extended to cope with symbolic and expression manipulation can be implemented efficiently to provide statement incremental compilation and execution in a multiprogramming environment. | |||
| The Slave Interactive System: a one-user interactive executive grafted on a remote-batch computing system | | BIBA | Full-Text | 225-240 | |
| Kenneth J. Busch; Gottfried W. R. Luderer | |||
| The Slave Interactive System (SIS) is a software system that makes available an interactive computing facility on a multiprogramming, remote-batch computer system. SIS runs under the computer's operating system in the same manner as a batch (or slave) job. The other slave programs continue as background work during an interactive run. However, SIS is intended to serve only one interactive user at a time; it is not built for multiple-access, time-sharing usage. SIS is a research vehicle designed to continue exploratory programming in user-oriented computing which requires a high degree of interaction and system flexibility. | |||
| The development of systems for on-line mathematics at Harvard | | BIBA | Full-Text | 241-256 | |
| Adrian Ruyle | |||
| Project TACT (Technological Aids to Creative Thought), in the Aiken Computation Laboratory of Harvard University, has been designing, implementing, and using on-line systems since 1964. Our investigation has concentrated on a rather small class of interactive systems which are "dedicated," that is, tailored to provide a coherent set of tools for mathematical assistance, and which use fairly powerful terminal facilities: display scopes and natural input. | |||
| An analysis of computer operations under running time priority disciplines | | BIBA | Full-Text | 257-270 | |
| E. G., Jr. Coffman | |||
| Running-time priority disciplines for sequencing computer operations are those which discriminate among programs on the basis of the amount of service (running-time) they require. Discrimination is explicit in the models analyzed by Kesten and Runnenburg [1] and Miller and Schrage [2] in which the priority rule is shortest-job-first. However, in the models of particular interest in this paper, the discrimination is necessarily implicit since it is assumed that the running-times of arriving programs are not known in advance. We shall now describe in detail the queuing models to be analyzed in the following sections. Our initial description will use conventional queuing terminology; subsequently, the correspondences between this terminology and the terminology of our particular application will be established. | |||
| A message system for interactive dialog | | BIBA | Full-Text | 271-283 | |
| G. C. Patton | |||
| When writing programs for interactive computer systems, programmers often find that it is difficult to develop the interactive dialog these programs require. The difficulty arises for two reasons. First, because interactive terminals are relatively new, programmers are not accustomed to planning and developing computer dialogs. Second, there is often no easy way to program the dialog once it has been developed. The solution to the first problem is heavily dependent on the programmer, his training and his background, and does not lend itself to a computerized solution. The solution to the second problem, however, can be eased by providing a higher-level, dialog construction language. The basic features for such a language appear in several systems used for computer-aided instruction [1-4]. The Message System builds on these features to provide a dialog construction language for general use. | |||
| A macroscopic model of an interactive computing system | | BIBA | Full-Text | 284-285 | |
| James N. Haag | |||
| The development of effective performance evaluation techniques for interactive systems is a complex problem [1,2]. Numerous papers have presented evaluation models based upon queuing theory [3,4]. This paper presents an alternative model which is quite general since it is independent of the microscopic properties of any given interactive system. By supplying to the model from four to seven experimentally determined parameters for a given interactive system, we can compute a numerical throughput optimization factor, and also a demand optimization factor in the case of time-dependent demands from the terminals. Additionally, for systems meeting a small number of restrictions, the model predicts quantitative relationships between the throughput and the implementation of techniques such as that of dynamically varying the scheduling algorithm. | |||
| A content-evaluating mode of computer-aided instruction | | BIBA | Full-Text | 286-293 | |
| G. K. Manacher | |||
| In the literature describing the languages and systems available for writing teaching programs, two main lines of development have been apparent [1]. At one pole is the system using the linguistic mode. Here, the student interacts "verbally" with the computer, in the sense that messages are sent to the computer by him and are then interpreted "verbally" by the machine. By this we mean that the steps the computer takes assume that the words received need not be decoded further; that is, the words themselves make up the target language. | |||
| OLDAS: an on-line continuous system simulation language | | BIBA | Full-Text | 294-297 | |
| Richard P. Cullen | |||
| OLDAS (An On-Line Digital Analog Simulator) is a tool for the simulation of continuous systems, or more simply, for the solution of differential equations. It is a conversational system that provides a user with the means to construct, modify, and run programs written in the MIMIC language [1]. | |||
| On the construction of polyalgorithms for automatic numerical analysis | | BIBA | Full-Text | 301-313 | |
| John R. Rice | |||
| This paper presents a summary of the experiences and viewpoints in the development of polyalgorithms for NAPSS. The polyalgorithms depend essentially on their objectives which are presented and discussed in the next section. The objectives of the NAPSS polyalgorithms are quite high and the four primary difficulties (met so far) in achieving them are discussed in the third section. These four difficulties are common sense, error control, flexibility versus simplicity, and reliability versus efficiency. Some of the approaches used in NAPSS to overcome these difficulties are given. | |||
| A proposed numerical accuracy control system | | BIBA | Full-Text | 314-334 | |
| Herbert S. Bright | |||
| A scheme is proposed for permitting a user of conventional procedural programming languages (initially, Standard FORTRAN) to test actual error propagation in numerical calculations. The process is to be fully mechanistic so that, with no human resequencing required or permitted, a "numerical procedure debugging" tool is made available. Other goals include a quantification of the order-of-precision decision for specified accuracy, provision of an observational tool for determining word length requirements, and an automatic facility for utilizing other kinds of arithmetic interpretively in executing existing programs and program segments. The experimental package consists, in effect, of a compiler from FORTRAN source language into an artificial machine language in which arithmetic operations produce, in addition to numerical results, a measure of the current accuracy of each result operand. | |||
| A learning program for the integration of systems of ordinary differential equations | | BIBA | Full-Text | 335-340 | |
| L. J. Gallaher; I. E. Perlin | |||
| In our previous work [1, 2], an effort was made to determine which of the many methods and orders available for the numerical integration of ordinary differential equations was best. While it was possible to show that, under certain circumstances, some methods and orders outperformed others, no one method was clearly superior under all circumstances. | |||
| On experiences with PIL, an interpretive language, in an undergraduate numerical methods course | | BIBA | Full-Text | 341-342 | |
| Joseph B. Muskat; Francis E. Sullivan; Paul R. Borman | |||
| The University of Pittsburgh's numerical calculus course acquaints students with various algorithms for interpolation, functional approximation, numerical differentiation and integration, and solving nonlinear equations. Computational and coding efficiency, regions and rates of convergence, and effects of errors are stressed. | |||
| Curve fitting and editing via interactive graphics | | BIBA | Full-Text | 343-345 | |
| Arthur S. Priver; Barry W. Boehm | |||
| The system described here allows a user to enter a curve into an IBM 360/40
computer via a RAND tablet [1], and interactively to specify various ways of
fitting, editing and displaying the curve on an IBM 2250 scope (see Fig. 1). It
was developed primarily as a tool to extend the analysis of multivariate
function representation (described by Boehm [2]) from tabular methods to
polynomial methods. We decided to use an interactive graphics approach for
three main reasons:
1. Experience has shown that much time is spent visually editing curves for input errors; this used to be done on an SC-4020 with one-day turn-around. 2. We wanted to experiment rapidly with choice of form, as multivariate functions are hard to classify in terms of representability. 3. The facility was available, along with a basic software support package. | |||
| FORTRAN codes to fit curves interactively | | BIBA | Full-Text | 346-348 | |
| Lyle B. Smith | |||
| In the past, data fitting has usually involved a computer program for the computations, and plotting the fit (usually by hand) to be sure of a "good" fit. | |||
| Analyst Assistance Program (AAP) | | BIBA | Full-Text | 349-354 | |
| Anne B. Ammerman | |||
| Analyst Assistance Program (AAP) is an on-line graphically oriented conversational computing system designed to perform small nonrecurring numerical computations. It is implemented to run under a multiprogrammed time-shared system (developed at the U. S. Naval Weapons Laboratory) on an IBM 360/40 computer. AAP is currently operational via two user consoles consisting of an IBM 2250 cathode ray tube display with alphanumeric keyboard and light pen, and a slow speed printer. The system is reentrant, and thus is capable of driving more than two terminals, if available. | |||
| Mathematical laboratories: a new power for the physical sciences | | BIBA | Full-Text | 355-384 | |
| Glen J. Culler | |||
| The concept of a mathematical laboratory has been developing throughout the lifetime of computers. The capabilities made available in systems supporting these laboratories range from symbolic integration, differentiation, and polynomial and power series manipulation, through mathematical simulation, to direct control experimental systems. About 1961 two trends, one toward what has become known as "on-line" computation, the other toward "time-sharing" had gained enough recognition to develop national support, and subsequently they have come to represent what is now known as modern computation. An on-line system provides interactive facilities by which a user can exert deterministic influence over the computation sequence; a time-sharing system provides a means by which partial computations on several different problems may be interleaved in time and may share facilities according to predetermined sharing algorithms. For reasons of economy it is hard to put a single user in direct personal control (on-line, that is) of a large-scale computer. It is equally (or even more) difficult to get adequate computation power for significant scientific applications out of any small-scale economical computer. Consequently, on-line computing has come to depend upon time-sharing as its justifiable mode of implementation. On the other hand, valuable on-line applications have formed one of the major reasons for pushing forward the development of time-sharing systems. At present, both efforts have reached such a stage of fruition that we find many systems incorporating selective aspects of the early experimental systems of both types. | |||
| Implementation of a Reckoner facility on the Lincoln Laboratory IBM 360/67 | | BIBA | Full-Text | 385-389 | |
| Peter B. Hill; Arthur N. Stowe | |||
| Another paper in this volume [1] has presented the concept of coherent programming as it is embodied in the Lincoln Reckoner [2]. The term "coherent" implies a set of programs which may be independently developed, perhaps written in different languages, but which nevertheless operate on each other's results and call each other. This concept is being used to build a Reckoner facility on the IBM System 360 Model 67 at Lincoln Laboratory. | |||
| The implementation of APL\360 | | BIBA | Full-Text | 390-399 | |
| L. M. Breed; R. H. Lathwell | |||
| APL\360 is an experimental, conversational System/360 implementation of APL, the Iverson language. It provides fast response and efficient execution to a large number of typewriter terminals. With 40 to 50 terminals connected and in normal use, each with a block of storage (called a workspace) allocated, reaction time (defined as the time from completion of an input message until the user's program begins execution) is typically 0.2 to 0.5 second. At the terminal this is manifested by nearly instantaneous response to a trivial request. Under these conditions, the CPU is executing user programs about 75% of the time, while supervisor overhead and I/O waiting time amount to less than 5%. The APL processor is interpretive; however, because of the efficiencies afforded by array operations, program execution is often one-tenth to one-fifth as fast as compiled code. APL\360 is currently running on a System/360 Model 50 with 262,144 bytes of core storage, a 2314 Direct Access Storage Facility, and two 2702 Transmission Control Units to which IBM 1050 and 2741 Communication Terminals are connected via telephone lines. | |||
| Implementation considerations in a numerical analysis problem solving system | | BIBA | Full-Text | 400-410 | |
| Roger V. Roman; Lawrence R. Symes | |||
| It has become apparent in the last few years that while general-purpose, problem-oriented computer languages have greatly eased the man -- machine communication problem, a great deal remains to be accomplished if the computer is to realize its full potential. | |||
| An implementation of automatic array arithmetic by a generalized push-down stack | | BIBA | Full-Text | 411-422 | |
| Juris Reinfelds | |||
| One of the most fundamental and useful notions of mathematical analysis is the concept of a continuous, single valued function of one independent variable. By y = f(x) we mean that for every x in the range of x, defined as α ≤ x ≤ β, the mapping f provides us with a value in the domain of the function yα ≤ y ≤ yβ, where yα = f(xα) and yβ = f(xβ). In a numerical computation we represent the part of the range of the independent variable, which is of interest to us, by a suitably chosen ordered set of n + 1 values (x0, x1, x2, ..., xn), and a representation of any function over this range is theN found by evaluating y = f(x) at these points, to obtain a corresponding ordered set of values (y0, y1, y2, ..., yn). Because of the obvious analogy, these arrays of numbers representing continuous functions are often called vectors. However, a semantic problem arises when we discuss vectors of functions, such as the vector potential or the wind velocity patterns in the atmosphere. Therefore, I prefer to make a special case of the representations of continuous functions and refer to them as arrays rather than vectors. | |||
| An example of the manipulation of directed graphs in the AMBIT/G programming language | | BIBA | Full-Text | 423-435 | |
| Carlos Christensen | |||
| AMBIT/G (AMBIT for Graph Manipulation) is a language for the manipulation of directed graphs. The data on which an AMBIT/G program operates is displayed as an actual diagrammatic representation of a directed graph, and not some sequential encodement of a graph. Furthermore, AMBIT/G statements are themselves written as directed graphs. The programmer works in terms of these diagrams throughout the conception, composition, checking, and execution of an AMBIT/G program. | |||
| Syntax-directed recognition of hand-printed two-dimensional mathematics | | BIBA | Full-Text | 436-459 | |
| Robert H. Anderson | |||
| Research in the real-time recognition of hand-printed characters [1-5] offers the possibility of drawing mathematical expressions on a RAND Tablet [6] or similar input device, and obtaining a list of the characters and their positions in an x-, y-coordinate system. This paper discusses the use of a set of replacement rules to recognize, or "parse," such two-dimensional configurations of characters. The replacement rules might be considered to be a generalization of the context-free Backus Normal Form rules used to describe a class of syntaxes for character strings. | |||
| A model for interactive systems design | | BIBA | Full-Text | 460-461 | |
| Helen M. Willett | |||
| This paper describes a model for the representation of interactive information systems. In terms of the model, it is possible to specify the performance and characteristics, internal and external, of the system. The system designer can adjust the organization of the data, the search and retrieval algorithms, and the operational appearance of the system. | |||
| Summary | | BIBA | Full-Text | 462-466 | |
| Burton D. Fried | |||
| Rather than attempting to summarize or evaluate the material presented in this volume, I shall give one user's reaction to what he learned, without trying to mention explicitly all of the interesting and worthwhile contributions. By and large, the state of the art as revealed in these papers is encouraging. In my paper "On the User's Point of View" I listed 10 desiderata for an on-line system. Three years ago, one could look in vain for any system, other than those developed by Glen Culler, which satisfied an appreciable number of these. Today there are several which do, and it is clear that the direction of their evolution is such as to satisfy more of these criteria. Those concerned with such systems might consider an additional figure of merit: the number of Ph.D. theses in user areas; or, the number of technical papers published by users (in journals of applied mathematics, physics, chemistry, engineering, etc.), whose results have been obtained, in part, using such interactive systems; or, in industrial environments, the number (or value) of proposals for technical contract work won by virtue of such systems' help to users. | |||