From this point on, the numbering of groups corresponds to the intermediate revisions of Groups16 and to Groups32. The duplicate groups have been eliminated, and the numbering for groups of orders 1-16 is changed. Eventually groups of orders 17-32 will be added.
In the transition to Groups32, I made a number of changes. ID appears so often in the code above because we stored group elements as A, B, C, … , and we often need to use the corresponding numbers 0, 1, 2, … to access tables or arrays. We have already pointed out that the group multiplication word G* would be faster if this conversion from the letters to indices were eliminated. I changed the group tables to store 0, 1, 2, ... for the elements, which required revising many of the existing words that use tables and arrays. GLIMITS (which put loop limits on the stack) was renamed to For-All-Elements, and the limits are now indices rather than ASCII codes. The words /A, /B, /C, … that put ASCII codes on the stack were changed to put 0, 1, 2, … on the stack. I changed the display word .ELE from
: .ELE ( ele -- ) EMIT SPACE ;
to
: .ELE ( ele -- ) ID + EMIT SPACE ;
Reminder: Code in red was in the early 1990 version, Groups16; Code in green is in the current Groups32; Blue represents code that was not in the 1990 version and did not survive to Groups32.
These changes were not as disruptive as it might seem at first. Many of the words in the system are not aware of how the data are represented and so required no change.
A consideration in implementing a system is precisely this: Can the programming be done in such a way that details of data representation are hidden in lower level words? Do most of the words in the system need to know whether group elements are represented by indices or by ASCII codes? Do most of the words in the system need to know where or how the data are stored?
These questions have repercussions when changes are made in the system. They also have psychological repercussions: How much is the mathematician allowed to think in terms of mathematical objects (groups, elements, etc.), and how much must he or she think in terms of computer representation. The purpose of some of the changes in this transition is to make the language and concepts more in terms of mathematical objects and procedures applied to them. Even the small change in name from GLIMITS to For-All-Elements is significant.
I had an important change in attitude in the transition: Several procedures were originally written to produce output on the screen -- they were regarded as top-level. I found while extending the system that it would be useful to separate the generation of information from printing it. An example of this is a factoring of the Orders command (discussed previously) into a procedure to calculate the orders of elements and a procedure to print them:
: Orders ( grp# -- ) CR >Group ." Group number " Gnum . ." of Order " Gord . CR Calc-Orders Prt-Orders ;
This allows other commands to use information about orders of elements. This, in turn, required the development of data structures that could be used to transmit information from one procedure to another. In the case of subgroups and sets, it involved representing data in a form that could be transmitted on the stack. In the case of element orders, it meant providing other procedures access to the locations in memory where data were stored.
The transition also was marked by the addition of other features -- most notably, a way to deal with subgroups and a permutation group package -- plus refinement of existing features.