[bug#47237] [PATCH] gnu: metis: Use 64-bit floating pointer numbers on 64-bit architectures.

[Emmanuel Agullo]

Hi Simon,

> I am probably out-of-scope, and it does probably not make sense for
> partitioners as Metis, how are considered mixed precision solvers?
> i.e., computing some part using 64 bits floating points and other part
> using 32 bits.  (My memory is not clear but I remember reading couple of
> weeks ago an acceleration with 3 levels of float-pointing precision.)
> 
> In the i32_r64 example of convention, what should be considered as rXY?
> The final accuracy, whatever the internals?

You are right, in principle, there are many combinations we would
like to consider and I don't think combinatorial or numerical library 
developers have followed a unique common rule.

I would say that most fully-featured numerical libraries have an
interface for all four main floating-point arithmetic (s, d, c,
z, to follow blas/lapack convention). Therefore, for most of them,
a single package should be enough regarding floating-point 
arithmetic. The same is true for mixed precision routines
(such as the dsgesv mixed precision lapack solver with iterative refinement
http://www.netlib.org/lapack/explore-html/d7/d3b/group__double_g_esolve_ga05bea3dc0386868e4720f22c969cb9f5.html
 ).

On the other hand, as I understand, currently, integers are not
handled the same way. There is of course always the option
to force the compiler to turn all integers in a give arithmetic
but advanced combinatorial and numerical codes provider finer
strategies. In fully-featured combinatorial codes such scotch 
(and if I understand metis), the selection is made at compile
time. In guix, for instance, the scotch and scotch32 package 
position INTSIZE64 and INTSIZE32, respectively. [In this
case, symbol renaming would be necessary to implement
algorithms dealing with subgraphs in 32 bits and other
subgraphs in 64 bits (a "mixed integer arithmetic") but 
I would say that is out of the scope of immediate needs 
for the guix community, or, that should at least be discussed
with library developers ahead of time before being packaged
as they may provide facilities in upcoming releases]. The most 
advanced fully-featured numerical codes may also provide selective 
64-bit integers in order to handle large problems while maintaining 
most arrays in 32-bits (one may want to have a look for instance at the
Section 2.6.2 of the 5.3.5 mumps user's guide
for such an example
http://mumps.enseeiht.fr/doc/userguide_5.3.5.pdf ). This
is typically useful for sparse direct solvers (such as mumps)
which may have to cope with very large matrices with billions
of entries. On the other hand, it is much less common to process
such large dense matrices in dense (except possibly for level-1 
blas routines), this is why large integer arrays are most often
consitently 32 bits in dense routines.

To come back to your original question:

> In the i32_r64 example of convention, what should be considered as rXY?
> The final accuracy, whatever the internals?

I would say, at least for now, to focus only on the options
that library developers have proposed to position at compile
time in their makefiles. For scotch, it is already distinguished 
through the scotch and scotch32 pakages (however we may still want
to make sure the naming convention is clear). For metis, *if I 
understand correctly*, there is the option to position both integers and
floating-point numbers, hence maybe the four combinations
that could be considered (but I have no experience in dealing 
with floating-point numbers in metis).

Hope this helps.

Best regards,

Emmanuel