[qv]<IDL>History>DesignMemos.dm!1>Design.Generators

This brief note records two problems and some observations on the behavior of generators which were noticed when considering the use of generators to enumerate the elements of selected arrays.

There is a problem with generators for symmetric arrays. If generators are defined to enumerate the elements present in the element block (i.e. only the elements in the lower triangular section for a symmetric array) then expressions of the form A+B, for A symmetric and B full, will not work correctly, as there will be different numbers of elements in the two arrays. On the other hand, if the logical, rather than the physically present, elements are enumerated, then A+B for both A and B symmetric will produce a full array! (A problem that occurs in the present code, and which would also cause them to print full had we not taken evasive action in PRETTYPRINT.)

Of the two situations, I think that the latter is less troublesome. It would be simply unthinkable to have all system code check the format of its arguments before setting up generators for them, and compute compatible logical/physical switch settings as arguments to their generator SETUPs. I feel that we would probably drop symmetric arrays from the system before resorting to this solution. Consequently, we have the principle

We now note that the problem with symmetric arrays becoming full can be split into two parts. First, it is discrepant with the currently defined user semantics and, second, the computation is less efficient than it should be. The discrepancy with the user semantics, is the most important, and luckily, it can be finessed. In those cases where the result of a system routine is symmetric, it is because either the system routine knows that it produces a symmetric result (e.g. SWEEP), or because the format is inherited from the input. In both these cases, the array that is to be output can be allocated symmetric and filled by logical element (i.e. as if it is full). This will have the same effect, at the cost of setting each off-diagonal element twice. My feeling is that we can live with this inefficiency for the time being, and make some special case improvements to MAP (as we did to PRETTYPRINT) if it continues to bother us.

The second problem with generators is that the new code for using a generator to enumerate a selected array will not work if the base array is a functional generator, as it is assumed that address arithmetic can be done on the (assumed) simple array which forms the base. (Note that we would have the same problem with a selected array in the base slot were we not (in AT.COMPOSE) preventing the nesting of selectors.) Consequently, when we implement functional generators, we either have to change this code or implement generator tree simplification (i.e. moving selectors through functional generators, so that, for example, (A+B)@mumble becomes (A@mumble)+B(@mumble) ). This is clearly very lovely stuff, and is not too far removed from what we do already in composing selectors (so that (A@X)@Y becomes A@Z, for some equivalent Z) but it probably requires some thought.