The theme of this conference is "On Track to the 21^st Century." We are using a railroad motif this year because Scranton is the home of one of the largest collections of steam trains in the world-the Steamtown National Historic Site. We also wanted to emphasize that this is the last APL conference before the infamous Y2K problem occurs.

Generalization of pick's theorem for surface of polyhedra

The Pick's theorem is one of the rare gems of elementary mathematics because this is a very innocent sounding hypothesis imply a very surprising conclusion (Bogomolny 1997). Yet the statement of the theorem can be understood by a fifth grader. Call a polygon a lattice polygon if the co-ordinates of its vertices are integers. Pick's theorem asserts that the area of a lattice polygon P is given by A(P) = I(P) + B(P) / 2 - 1 = V(P) -B(P) /2 - 1 where I(P), B(P) and V(P) are the number of interior lattice points, the number of boundary lattice points and the total number of lattice points of P respectively. It is worth to mention that the I(P) (understand like digital area) is digital mapping standard in USA since decade (Morrison, J.L. 1988 and 1989). Because the Pick's theorem was first published in 1899 therefore our planned presentation had timing its 100 anniversary. Currently it has greater importance than realized heretofore because of the Pick's theorem forms a connection between the old Euclidean and the new digital (discrete) geometry. During this long period lots of proof had been made of Pick's theorem and many trial of its generalization from simple polygons towards complex polygon networks, moreover tried to extend it to the direction of 3D geometrical objects as well. It is also turned out that nowadays the inverse Pick's formulas comes to the front instead of the original ones, consequently of powerful spreading the digital geometry and mapping. Today the question is not the old one: how can we produce traditional area without co-ordinates, using only inside points and boundary points. Just on the contrary: how is it possible to simply determine digital boundary and digital area (namely the number of boundary points and inside points) using known co-ordinates of vertices. The inverse formulas are: B(P)=GCD(X,Y,Z) (1D Pick's theorem) and I(P)=A(P)- B(P)/2+1 (2D Pick's theorem) where GCD is the Great Common Divisor of the co-ordinate differences of two-two neighboring vertices. The our main object is not these formulas to present, but we desire to show that the Pick's theorem (after adequate redrafting) indeed valid for every spatial triangle which are determined by three arbitrary points of a 30 lattice. The original planar theorem is only a special case of it. However if it is true then its valid not only for triangles but all irregular polygons also which are lying in space and have its vertices in spatial lattice points. Finally if the extended Pick's theorem is true for all face of a lattice polyhedron then it is true for total surface as well. Consequently we developed so simple and effective algorithms which solve enumeration tasks without the time- and memory-wasting immediate computing. These algorithms make possible that using the vertex-co-ordinate list and the topological description of a convex or non-convex polyhedron (cube, prism, tetrahedron etc.) getting answer many elementary questions. For example, how many voxels can be found on the complex surface of a polyhedron, how many on its edges or on its individual faces. We succeeded to extend our results also to the surface of non- cornered geometric objects (circle, sphere, cylinder, cone, ellipsoid etc.), but anyway, this have to be object of another presentation.

[Full Text in PDF Format, 927 KB]

When bears are blue and bulls are red

Analysts deal with real numerical data. Often the data is collected over time. Because numbers are abstract, analysts often use graphs to make numerical data more meaningful. Real data typically fluctuates in some random fashion. However, patterns often exist in the data. An example would be the seasonal fluctuations in commodities. Analysts use a variety of techniques to help them find patterns that have the potential to improve their skill in predicting future trends. This paper suggests some ways to make some of these patterns more obvious.

We are here presenting techniques to enhance traditional methods of providing information in graphs. By taking advantage of current computer technology to provide graphic images and to draw graphs, new and exciting visual images are possible. In addition, animation strategies allow us to simulate the passage of time. Finally, we add a whimsical touch.

By animating the graphs of mathematical functions we illuminate aspects of the graphing process which might otherwise go unnoticed. The focus of this paper is on curve fitting. APL and J provide the matrix divide function for finding the coefficients of the constant, linear, quadratic, cubic or nth degree polynomial which best fit a collection of data.

Each of these polynomials also has a polynomial derivative. These derivatives are useful for three reasons. Select a point on the x-axis. The y-value of the polynomial is the height of the polynomial for that x-value. But the y-value of the derived polynomial for the chosen x-value provides information about the original polynomial in three ways. First the y-value for the chosen x-value is the slope of the original polynomial at that point. The second useful aspect of the derivative is that positive and negative values indicate when the original polynomial is increasing or decreasing. A derivative is one degree less than the original polynomial so for example, a cubic polynomial has a quadratic polynomial derivative.

[Full Text in PDF Format, 422 KB]

Dynamic systems simulation using APL2

In this paper, we describe methods, models and software applied for dynamic system simulation using APL2. Keywords Aggregate approach, piecewise linear aggregate, simulation, combined modeling, dynamic system, programming language APL2.

[Full Text in PDF Format, 570 KB]

Functions and data can dance as equal partners

It is difficult today to think of machines of the early fifties. A vaguely recollected machine, which probably combines features of more than one real machine, had as memory a rotating drum. The instruction format included an operation code and four addresses. The first three addresses were not unusual: the locations of two operands and the result of the operation. The fourth address was the location of the next instruction. A programmer had to pick a spot on the drum that will be under the read head when the instruction finishes. It required a bit of ingenuity and lots of experimentation to get the most out machines from that era. The job was not made any easier by the fact the machines typically had about a thousand words of storage.

It was not long before assemblers and compilers took over the job of managing machine operations. Programs were divided into two major sections: procedures and data. The small storage capacity raised a problem: to store all numbers with the same number of bits required a choice. If the word size was small, precision was limited; if large, relatively few numbers could be stored. A compromise was reached by storing numbers in several different formats that used more storage when greater precision was required. Data-types had arrived.

It was to be a several years before the term polymorphism was applied in the computer field. An early use of the word is cited in the OED: "The various portraits of her majesty astonish by their perplexing polymorphism.. ." [1839 Fraser's Mag. XX. 699].

Compilers in the fifties required a set of declarations that preceded the executable code. The names of variables were classified into groups that specified the storage formats of their respective members. Different instruction sequences were needed to perform arithmetic on differently formatted numbers.

Nonnumeric data was a category by itself. Before long nonnumeric subcategories, i. e., data-types, were recognized. Some of them formed nested sequences, just as the early numeric types - bits, small integers, large integers, and floating point - formed a natural sequence. The domain of a function was the set of data-types on which it could operate.

A typical OOPS requires declaration of the data-types and functions that apply to them in a different way. Instead of considering functions and the data-types that they can accept, it considers data-types and the sets of functions that can use them. As in the case of FORTRAN, declarations must be complete before programming begins. The sets of functions could be thought of as function-types, although the term has been little used, if at all.

No matter just how the information on data and function types were stored in the early computer and compiler days, and no matter whether they were stored with the CPU or on disk or drum, not many thought then about arrays of functions. The Michigan Algorithm Decoder (MAD), a compiler of the late fifties, is the only place I know of which supported indexed function name variables.

[Full Text in PDF Format, 395 KB]

The Zark library of utility functions

The primary appeal of APL has always been its productivity. You can develop and maintain computer applications faster with APL than with any other high-level programming language. APL has a number of distinct traits that contribute to this productivity advantage over other languages. However, language productivity is only one side of the programmer productivity triangle. The other two are programmer experience and utility software. The programmer with the most productive language, the most experience, and the best utility software will develop better code, and faster than the programmer who is deficient in any of these three areas. Experienced APL programmers generally score well in the first two areas, but poorly in the third, probably because APL obviates the perceived need for high quality utility software. Programmers in other languages do not have this lwtury and so tend to develop and rely upon more extensive and higher quality utility software. Consequently, the productivity advantage of APL programmers over other programmers is not as significant as it can be. ZarkLib, the Zark Library of Utility Functions, is a scheme that attempts to remedy this problem. It is both an extensive collection of APL utility software and a motivational scheme. It guarantees its growth and maintenance by employing a "pyramid" scheme that motivates APL programmers to give until it hurts, and then give again.

[Full Text in PDF Format, 538 KB]

Choices in server-side programming a comparative programming exercise

One of the fastest growing and changing fields for software developers is in writing applications that are used across the "World Wide Web", which is in turn a client-server system that runs on the Internet. Servers, known by name, can be accessed over the Internet, and a protocol, known as HTTP (Hypertext Transfer Protocol) is used to send requests to servers for text, images (still and moving), audio, and other information. A very large amount of business will be conducted this way, now and in the future, having grown from almost nothing only 5 years ago. Application development on the Web is largely a matter of writing programs that are executed by the server, and we're going to focus our attention on two programming and operating environments that can be used to deliver server-side software.

We would like to show how APL can be used to develop programs that run on the server, and we will contrast it with another means of developing and delivering server-side programs. It is not our goal to deliver any judgment about whether or not one system is "better" than the other (we believe that any such statement would be simplistic to the point of being misleading); we intend only to share the results of our experience, help the reader understand what technologies that are available, and assist in making an informed choice if participation in a project of this nature is part of what the reader does.

[Full Text in PDF Format, 730 KB]

Regions: an abstraction for expressing array computation

Most array languages, including Fortran 90, Matlab, and APL, provide support for referencing arrays by extending the traditional array subscripting construct found in scalar languages. We present an alternative to subscripting that exploits the concept of regions,-an index set representation that can be named, manipulated with high-level operators, and syntacti,cally separated from array references. This paper develops the concept of region-based programming and describes its benefits in the context of an idealized array language called RL. We show that regions simplify programming, reduce the likelihood of errors, and enable code reuse. Furthermore, we describe how regions accentuate the locality of array expressions and how this locality is important when targeting parallel computers. We also show how the concepts of region-based programming have been used in ZPL, a fully-implemented practical parallel programming language in use by scientists and engineers. In addition, we contrast region-based programming with the atray reference constructs of other array languages.

[Full Text in PDF Format, 1072 KB]

Accelerating APL programs with SAC

The paper investigates, how SAC, a purely functional language based on C syntax, relates to APL in terms of expressiveness and run-time behavior. To do so, three different excerpts of real world APL programs are examined. It is shown that after defining the required APL primitives in SAC, the example programs can be re-written in SAC with an almost one-to-one correspondence. Run-time comparisons between interpreting APL programs and compiled SAC programs show that speedups due to compilation vary between 2 and 500 for three representative benchmark programs. Keywords: Language Comparison, SAC, Compilation, Runtime Performance.

[Full Text in PDF Format, 860 KB]

Sparse arrays in J

We describe a sparse array extension to J using a representation that "does not store zeros". One new primitive $. is defined to create and manipulate sparse arrays, and existing primitives are extended to operate on such arrays.

[Full Text in PDF Format, 230 KB]

INFO: Interactive APL documentation

A large body of APL code may be hard to understand and analyze, particularly if you are not its author. A code system that spans multiple workspaces (WSs) compounds that problem.

INFO is a Multi-WS system written in APL+Win that provides convenient interactive documentation of APL+Win and APL+DOS multi-WS systems. The User has a variety of displays that give insight into the system structures and relationships within single- or multi-WS systems. An administrator can easily set up and maintain the INFO static analysis data bases for any number of WS groups. This paper demonstrates INFO by showing how INFO documents itself. A distribution package contains the complete code and instructions for setting up this self-documentation.

[Full Text in PDF Format, 1569 KB]

A Retro/Prospective on APL graphpak

This paper suggests two general directions that one could take to modernize APL2 Graphpak and revitalize its evolution. One direction springboards off lessons learned during Graphpak's first decade and from some thinking that evolved during early (c. 1980) experiments with general arrays. The second direction exploits general arrays and APL2 functionality at a user-level. Some experiments are reported relating to both areas.

[Full Text in PDF Format, 1099 KB]

Teaching J as a Computer Notation for Secondary Mathematics

This article summarizes a teacher-education course which introduces .I as a computer notation well-suited for teaching secondary mathematics. This one-semester course is designed as a series of workshops with accompanying discussions. The first workshop is described here in detail; the others are sketched. Teachers' experiences and reactions to using J are reported informally throughout.

[Full Text in PDF Format, 701 KB]

An object-oriented Approach to Educational Software in Building Physics

An object-oriented building-physics software A.T.O.N. (which is the acronym for the German "General Thermal and Ecological Verifications") is described as an example for educational software written in APL. The software was immediately monitored in graphical windows. In order to developed at the Department for Structural Analysis at the Technical University of Graz, and has been successfully used achieve this "question & answer"-concept a hybrid system was for teaching building-physics. A.T.O.N. was designed in only four months. It comes with an user-friendly interface, which is set up. This system consists of quick C- and Fortran-DLLs easv and effortless to learn. Everv maniwlation of data is combined with the dyalogAPL^TM interpreter using CausewayPro^TM as an interactive development environment.

[Full Text in PDF Format, 354 KB]

APL-generated teaching and testing items to enhance a student's ability to discover functional relationships

Ideas and designs for programs to generate teaching examples are introduced. Some of these ideas are tested and demonstrated by a prototype APL program. Descriptions of the internal structure and requirements of the example generators are presented. The examples produced by the program are designed to motivate students to discover rules or relationships capable of mapping the in-domain inputs to correct outputs. Experimental examples used for demonstrating typical concepts and mathematical processes include the functions ½, ¼, ×, ÷, | and • with their intrinsic APL definitions. Initially, the types of arguments for these examples will be kept simple at first to promote learning such mathematical functions by permitting only single scalar arguments. Later, for discovery learning, the functions may be selected to permit or require arguments that are vector or array objects. An important component in the design of this system is parameter specification. Parameters determine the number of examples and their perspicuity. A student using the system may request additional examples that are easy to comprehend before the function is discovered from the program generated examples provided. The example-generating program also facilitates checking that establishes that a student's response is operationally equivalent to a correct one.

[Full Text in PDF Format, 580 KB]

GFSR pseudorandom number generation using APL

This paper demonstrates the effectiveness of APL for implementing the generalized feedback shift register (GFSR) approach to producing a random number stream. Various approaches to generating streams of pseudorandom numbers computationally have been devised, dating at least as far back as Norbert Wiener. These are normally discussed in the context of a course in modeling and simulation, since there may be practical implications to consider when building simulation models in APL or any other high level language. This is particularly the case for those circumstances when a (pseudo) random number sequence needs to be repeated, or when multiple streams are needed. In such cases a pseudorandom number generator other than that supplied in the programming language command set needs to be implemented. The linear congruential method for pseudorandom number generation is still commonly used, and is easily implemented in APL or any other high level language; however, it is known to have undesirable n-space uniformity characteristics. Moreover, the period length of its random number stream is limited by the underlying machine's word size. This is a serious issue, since at present day computer speeds, a simulation run could exhaust such a random number stream in a few hours. Very long' period (VLP) pseudorandom number generators remedy this deficiency.

One class of these, generalized feedback shift register (GFSR) pseudorandom number generators, is based on algebraic manipulation of irreducible trinomials of high order. The manner in which this is accomplished particularly lends itself to elegant APL implementation.

[Full Text in PDF Format, 381 KB]