Non-local blocks

Section 7.3 described the relatively easy-to-use
`localBlock()` inquiry. This inquiry returned block parameters for the
local coordinate value in the process dimension associated with the range.

There are other situations, for example inside the implementation of
communication functions like `Adlib.remap()`, where *all*
blocks--local *and* remote--of a subrange must be enumerated.

To deal with these situations there is a general method called
`block()`. This method takes one integer argument--a coordinate in the
process dimension associated with the range. Like `localBlock()`
it returns a `hpjava.lang.Block` object, defining the layout of
distributed array elements in that process. The `Block`
class was described on page .

One might expect the `block()` inquiry should be well-defined for any
valid process coordinate. But there are some array alignment options
that wouldn't be handled particularly well if that was true. Consider
the example array sections illustrated in Figure 7.21,
which presume the declarations:

The first example involves a narrow subrange of a block distributed range.
Only two of the six processes hold any elements of the array section.
This isn't a problem with for the simple version of block parametrization
presented in section 7.3--the `localBlock()`
inquiry will simply return ``empty'' blocks, with `count` set to zero.
When translating simple `overall` constructs, the overhead of
calling `localBlock()` unconditionally in all processes is not
a problem--the method is called at most once in each process anyway.
But in situations where *all* blocks--local *and* remote--of a
subrange must be enumerated it may become inefficient to blindly
work through every coordinate value, sifting through many empty blocks.

The second example in Figure 7.21, illustrates that
a similar problem can arise for the case of a strided section of a *cyclic* range. In this particular example half the processes hold no
elements. Again, blindly computing `localBlock()` for all coordinates
can lead to inefficiencies, especially in communication functions
(where this kind of situation actually arises quite naturally when
one is dealing with cyclic ranges).

The final example of Figure 7.21 is rather different.
It illustrates the case of an array section with a *negative*
alignment stride. The natural enumeration order for coordinates of blocks
is reversed here, and there are some situations where failure to take
this into account can lead to wrong results. In fact we already saw
one such example in section 7.6.