Re: identify floating-point types

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Theoretically, you should be able to use the types Interfaces.Fortran.Real
and Interfaces.Fortran.Double_Precision, and these should ensure that your
Ada code uses the correct types to interface to the Fortran library (see
RM95 B.5).

In practise, you might need to check your Ada and Fortran compilers'
documentation carefully, to see whether the types provided in
Interfaces.Fortran do truly match the corresponding Fortran types (on some
machines this will be a given thing, but not all).

Otherwise, I think your approach is basically sound.  One useful refinement
might be:

  is_single: constant boolean:=
                use_BLAS and
                real'digits <= Interfaces.Fortran.Real'digits;

  is_double: constant boolean:=
                use_BLAS and
                not is_single and
                real'digits <= Interfaces.Fortran.Double_Precision'digits;

This will (theoretically) allow a wider choice of floating-point types to be
passed into instantiations of the generic package.

An alternative idea would be to define two different generic packages,
perhaps named 'Single_Precision_Sparse_Vector_Functions' and
'Double_Precision_Sparse_Vector_Functions' (or maybe something slightly more
succinct!), and have the 'real' generic parameter derived as appropriate,
e.g.:

  generic
    type real is new Interfaces.Fortran.Real;
    type index is range <>;
    type vector is array(index range <>) of real;

  package Single_Precision_Sparse_Vector_Functions is

    ...

and:

  generic
    type real is new Interfaces.Fortran.Double_Precision;
    type index is range <>;
    type vector is array(index range <>) of real;

  package Double_Precision_Sparse_Vector_Functions is

    ...

These would compel the users of the packages to use types derived from (and
therefore precision-compatible with) the Fortran types (or, more likely, to
use the Fortran types directly).  You would then be spared, in the bodies of
these packages, the blight of 'if ... then .. else' statements all over the
place.

As an additional idea, you might be better off putting:

  use_BLAS: constant boolean:= true; -- use Basic Linear Algebra Subroutines

in as one of the generic parameters, so that users of the package can choose
not to use BLAS, if they wish.  Taking this a step further, you could define
two (or three) packages, one (or two) using BLAS and one not (thus avoiding
more 'if ... then ... else' blight).

(If you wanted to get _really_ fancy, you could declare an abstract tagged
type, say 'Abstract_Vector', with abstract operations corresponding to the
vector operations you require, and then derive two (concrete) types from
this abstract type, one implementing the operations using BLAS, and one not.
But this would _probably_ be slight overkill ;-)

You may also wish to investigate the optimisation possibilities of using the
Optimize (RM95 2.8) and Suppress (RM95 11.5) pragmas, and any other
optimisation facilities that may be provided by your compiler.

Hope this helps.

-------------------------------------
Nick Roberts
-------------------------------------