GL(ID:4403/com003)Language for 3d descriptionfor Geometry Language Comba IBM 1968 3-dimensional structure desription language References: Many branches of engineering and technology give rise to problems of a geometric nature that cannot be conveniently formulated and solved with currently available programming languages and systems. In this paper, we discuss in some detail one such problem (often referred to as the placement problem), we formulate the general requirements for a language that addresses itself to problems of this type, and we present an outline of the specific features that this language should have. For convenience and brevity, the proposed language is called Geometry Language (GL). A fuller set of specifications for GL may be found in Reference 1. It should be pointed out that GL has not been implemented. Language requirements The so-called placement problem is a major and recurring problem faced by the designer of physical systems (e.g., ships, chemical plants, jet engines). It arises when a large number of objects of many different shapes (components, subsystems, pipes, cables) have to be positioned in a restricted space in such a way that no two objects are assigned to the same space. The restriction that two objects cannot occupy the same space at the same time is, of course, a basic property of physical bodies. The problem of verifying that the plan of a system satisfies this no-overlap condition can be very difficult. Many techniques have been used in attempting to solve this problem12 and some of them have been partially successful in special situations. For example, one can subdivide the whole design space into a set of cubes and keep track of which cubes are occupied and which are free. The trouble with this approach is that either it is too coarse or it generates an exhorbitant amount of data. Both of these objections are avoided by the geometric and hierarchical approach of GL. Another aspect of the design process is the use of different media to represent the system being designed. At least three levels can be distinguished: Physical: scale models Graphic: sketches, drawings, blueprints Symbolic or abstract: equations, formulas, geometric concepts The Geometry Language is a tool for working at the symbolic or abstract level. If a scale model were used as the main design tool, the placement problem would vanish: since different physical elements of the model cannot occupy the same space, neither can the corresponding elements of the system. It is obvious, however, that this approach is impractical. In a typical design project, the specifications of the components and subsystems undergo a large number of changes before they reach final form, and many people must have access to those specifications. A scale model, on the other hand, is expensive and time-consuming to build and modify, not to mention the problems of duplication and dissemination. Furthermore, it may be difficult to read dimensional information off a scale model without taking it apart. The graphic approach to the placement problem is also inadequate, since it is impossible in general to represent fully a threedimensional object with curved surfaces on a flat surface such as a sheet of paper. A partial exception to this statement is the technique of stereographic three-dimensional views, developed by Straws and Poley3 to produce LLwire-framelJ representations of systems of pipes. If this technique can be extended to more complicated systems of objects, it is very likely that it will require an input language with many of the features of GL. We are thus led to the abstract approach. The feasibility of this approach has been recently dem~nstrated;~ specifically, it has been shown (for a certain class of geometric shapes) how the nooverlap condition can be formulated and tested directly in terms of the equations of the surfaces bounding the objects. The placement problem is an instance of a larger class of problems of space allocation, partitioning, and accessibility that occur in engineering and architectural design. It is the author?s contention that the most natural language for handling such problems is one that deals directly with the geometric properties of space. If the designer?s mind thinks in terms of planes, spheres, and cylinders, the language should deal with planes, spheres, and cylinders, and with the properties of these objects. In other words, the symbols used in the language should designate geometric objects and relations rather than graphic constructs. (Whether these symbols should be alphanumeric characters or pictographs is a separate question, to be discussed below.) The advances in engineering and technology in the last decades have made it possible to design systems of great complexity where hundreds of people are involved in the design process. This has brought about new problems of control and documentation: what space belongs to whom, and who has placed what where. A language for geometric processing must have facilities for deJining and handling sets and configurations of spacially and functionally related objects. The question whether the symbols of the language should be alphanumericharacters, or graphics elementsuch as points, lines, and curves, is related to the question whether the language is intended to be used in a batch mode or in an interactive mode. The point of view taken here may be summarized as follows: Both modes are necessary. Many geometric problems can be adequately expressed in a programming language where one writes statements on coding forms; it is then unnecessary and wasteful to use a graphics console. Conversely, there are problems where interaction is essential and where it is more natural to draw with a light pen or a stylus and to point to the elements of a figure. Although the ?written? and the ?pointing? language are intended for .different uses, one can establish a correspondence between the elements (variables, commands, etc.) of the two languages. In fact one can think of them as two forms of the same language. For this reason, only the written form of GL is discussed in this paper. Besides, the emphasis here is on what the language can do, i.e., on its meaning rather than its form. The approach advocated here can be contrasted with the design philosophy of the widely used Civil Engineering Coordinate Geometry System (COGO). COGO deals primarily with points, straight lines, angles, and circular arcs, whereas GL deals with solid objects and the surfaces bounding them. An engineer working with COGO ((writes the description of his problem and how to solve it as if he were solving it by hand?; in other words, he specifies a linear sequence of instructions. By contrast, GL is intended to be imbedded in a full-fledged programming language, with facilities for branching, looping, subroutine linkage, and interrupt handling. COGO operates on a simple data structure, whereas GL requires a complex data structure. Having established the need for a system for manipulating why three three-dimensional geometric figures, the question arises whether dimensions one should design a more general system to handle n-dimensional geometry; this system could then be used to solve problems in 2-, 3-, or 4-dimensional space. While this approach is appealing, it is quite impractical, as shown by the following considerations of efficiency and relevance. Eficiency. If the dimensionality n of the space is treated as a parameter to be set at execution time, the allocation of storage space for the data structures on which the system operates becomes more complicated. For example, the coordinates of a point would require a variable amount of storage depending on n. There is also another source of ineficiency: if all the problems that the system is intended to solve have to be formulated and coded in n dimensions, many subroutines will be much harder to write and test, and more time-consuming at execution time. Relevance. Many problems in three-dimensional geometry become either trivial or irrelevant or incompletely defined in a space of different dimensionality. For example, questions of visibility and calculations of shadows are relevant only in three-dimension, since the world in which we live is three-dimensional. A two-dimensional space (i.e., a plane) should not be viewed as a special case of a three-dimensional space, since a three-space contains infinitely many planes. (A system for three-dimensional geometry should, of course, provide facilities for defining planes a,nd for computing cross-sections of three-dimensional objects. The point here is that if the natural way to formulate a problem requires only twodimensional concepts, the problem should be solved by using a two-dimensional system.) In the opposite direction, the claim is sometimes made that problems involving time, as in kinematics and dynamics, require four-dimensional capabilities. Actually the time variable occurs only as a parameter and it does not interact with the space variables in the way these variables interact with each other. For example, while it is meaningful to rotate an object in space, it is usually meaningless to rotate it in space-time. The global entities on which the language operates are called models. A model is a data set containing a representation of a region of space and (in that region) of a system or assembly of graphic and/or physical objects. The process of building a model is analogous to that of creating or updating a file. Data is written in a file according to a specified format; analogously, geometric data is placed in a model with respect to a specified coordinate system. in IBM Systems Journal, 7(3 and 4) 1968 view details |