Most uses of ArrayRangeCompute just want to get the range of the data
and probably don't have a particular device in mind. Thus, it is better
to use a TryExecute internally use whatever devices are available.
Note that when using TryExecute, the calling code is expected to be able
to support all devices. That might not always be the case. Thus, I am
experimenting a bit with how we incorporate this in a library. The
advantage of having the code compiled in a library is that you only have
to compile it once and the calling code does not need to worry about
CUDA, etc.
However, because ArrayRangeCompute is templated, we can only pre-compile
some subset of array handle types. The most common are compiled into the
code (matching all the predefined ArrayHandles as well as some special
cases). If the code wants to use some other type, it has to include
ArrayRangeCompute.hxx. The only place where this is necessary is a test
that intentially trys to find the range on an uncommon type.
If array portals were to support virtual methods, then we should be able
to modify this code so that we could precompile for all array handle
types.
There are two versions of ArrayRangeCompute. The first version is a
general version that computes the min and max by running a reduction on
a device. The second version was a specialization for uniform grid
coordinate arrays, which is easily computed without looking at the
values.
The problem was that the generic version of ArrayRangeCompute took two
arguments and the specialization only took one argument (because it does
not need a device). This means that templated code uses the general
version will never use the specialized version. This fix adds a device
argument to the specialized version. The extra argument is not used, but
will properly overload the general version.
