Subject: Re: Last chance

From: "Rex Page" <[email-masked]>
Date: Thu, 17 Dec 92 11:20:31 -0600

Rob,

COPY_SCATTER:

There is a problem with the COPY_SCATTER definition that slipped
through all of our careful specification based on "mathematical
equivalence" and the like.  The problem is that the definition of
COPY_SCATTER relies on the expression   s1 @ s2 @ ... @ sm @ b
and the defintion COPY_operation(x,y)=x.  Because COPY_operation is
not commutative, the expression, without parentheses to specify the
order of application of the operations, is not well defined.

Here is my suggestion for fixing the problem:
Just after the definition of COPY_operation (i.e., just before the
paragraph beginning "Thus an element of the result delivered by
COPY_SCATTER ..."), insert the following sentence:
  When COPY_SCATTER combines source elements s1, s2, ..., sm with
  base element b, the processor may apply the operations in the
  expression s1 @ s2 @ ... @ sm @ b in any order it chooses (where
  x @ y denotes COPY_operation(x,y)).  

Since b occurs on the right in the expression, the processor cannot
select b as the result (because COPY_operation selects its first
argument as its result.  This is the intended effect of COPY_SCATTER
when, as in the case this part of the definition covers, there is a
non-empty set of source elements to be combined with a base element.

Mapping Inquiries:

The second paragraph of Section 3.1 (Motivation), which begins with
boldface "Result type, type parameters, and shape", is not really
needed because all of the information is repeated in the individual
definitions (as it should be).

If you decide to retain the paragraph, which I advise against,
I recommend using the terms "logical" and "integer" instead of
"default logical" and "default integer".  The paragraph will be
easier to read without the three occurances of  "default",
and it will mean the same thing.  Also, the term "rank one"
need not be mentioned in both the second and third sentences; I 
recommend taking it out of the second sentence, which should then read
something like "Integer results may be scalars or arrays."  The third
sentence ("Where a result is an integer array...") refers to the
dummy argument ARRAY, which hasn't been defined at that point; change
"ARRAY" to "the array whose distribution status is being requested".

The prototype headers for the inquiry subroutines specify all
the attributes of the INTENT(OUT) arguments except their intent.
The INTENT(OUT) attribute may as well be included in the list along
with type, OPTIONAL, etc.:
   e.g., INTEGER, INTENT(OUT), DIMENSION(:), OPTIONAL:: ...

All of the array INTENT(OUT) arguments except those in HPF_ALIGNMENT
are assumed shape.  I think it would be better to be consistent and
have them all be assumed shape.  Specific-shape arrays have some
restrictions on argument-passing mechanisms, so they should generally
be avoided anyway.  The text implies that LB, UP, and STRIDE have
at least as many elements as the rank of ARRAY, so there is no real
need for a specific shape declaration.

The definitions of LB and UB, as arguments of HPF_ALIGNMENT, use the
term "template coordinate".  I think I know what this means, but I
think it would be better to stick with more universal terminology.
How about something like this for LB (and something similar for UB):
  LB  An integer array.  The first element of the ith axis of ARRAY
    is mapped to the LB(i)th template element along the axis of the
    template associated with the ith axis of ARRAY.

In the list of optional arguments of HPF_TEMPLATE, and in the list
of definitions of those arguments, the argument TEMPLATE_RANK occurs
next to last and last, respectively.  Yet, TEMPLATE_RANK is the first
optional argument in the example header.  Why not list it in the same
relative position in the other references, following the lead of the
other definitions of the inquiry functions?

In the defintion of HPF_DISTRIBUTION, there is another anomaly in the
order of argument definitions:  PROCESSOR_RANK and PROCESSORS_SHAPE
are interchanged.

Rex