Machine parameters such as the relative machine precision, the underflow and
overflow thresholds, and the smallest value which can be safely reciprocated
(which in LAPACK is called `sfmin`), are frequently used in numerical linear
algebra computations, as well as in many other numerical computations. Without
due care, variations in these values between processors can cause problems, such
as those mentioned above.

Many such problems can be eliminated by using the *largest* machine
precision among all participating processors. In LAPACK routine `DLAMCH`
returns the (double precision) machine precision (as well as other machine
parameters). In ScaLAPACK this is replaced by `PDLAMCH` which returns the
largest value over all the processors, replacing the uniprocessor value returned
by `DLAMCH`. Similarly, one should use the smallest overflow threshold and
largest underflow threshold over the processors being used. The ScaLAPACK
routine `PDLAMCH` runs the LAPACK routine `DLAMCH` on each process in
the context and communicates the relevant maximum or minimum value. We refer to
these machine parameters as the **multiprocessor machine parameters**. `
DLAMCH` can also return the base, *b*, which nowadays is invariably *b* = 2, but
what we would do for `PDLAMCH` if we ever had a mixture of binary and
decimal machines in a network we leave as an open question!

Note that since `PDLAMCH` requires communication to each process in the
context, it suffers from the weakness that it cannot be called by a subset of
the processes (as might for example happen when a conditional statement such as
an `IF` statement is being executed), because processes will be waiting for
a communication which will never take place. There are many examples in
ScaLAPACK codes, however, where only a subset of nodes (for instance one column
or one row of the process grid) is performing a given computation, such as pivot
selection. ScaLAPACK has to avoid calling `PDLAMCH` from such computations.
Section 8 contains a specific example of this case.

For this reason, it is expected that the next release of the BLACS will support
caching based on the BLACS context. We will then be able to perform the
communication just once for each context and cache the values on the context.
Subsequent `PDLAMCH` calls within the context will then access strictly
local data, so will be more efficient, and thus may be safely called from code
performing computations on grid subsets.

Fri Aug 30 15:13:52 EDT 1996