Re: identify floating-point types

Re: identify floating-point types

[Nick Roberts]

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
-------------------------------------

Re: identify floating-point types

[Nick Roberts]

Thinking about this a little more, you need to be careful that the type
'vector' matches the corresponding Fortran vector (array) type.  I suspect
you will need the two separate packages, with:

   for real'Size use Interfaces.Fortran.Real'Size;

in one, and:

   for real'Size use Interfaces.Fortran.Double_Precision'Size;

in the other, to ensure that a change of representation has not been done.
In addition, I think you will need:

   pragma Convention(Fortran,real);
   pragma Convention(Fortran,vector);

to (help) ensure these types are stored in the same format as their Fortran
counterparts.

Hope this also helps!

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

Re: identify floating-point types

[robert_dewar]

In article <7cpk9t$s5o$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> 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).

Nick why do you say this? Have you run into an Ada 95
compiler where the types did not match? If so, it would
be a clear bug!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: identify floating-point types

[Nick Roberts]

Well, with some languages (notably C and C++), on some machines, there are
multiple parameter (and memory format) conventions.  But, I have to admit, I
think, in practice, Fortran conventions tend to be pretty consistent, for
any one particular architecture.  There's no harm in checking to make
absolutely sure, though.  (And, shocking as it may sound, compilers do have
bugs, occasionally ;-)

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

robert_dewar@my-dejanews.com wrote in message
<7csl7e$26b$1@nnrp1.dejanews.com>...
|In article <7cpk9t$s5o$1@plug.news.pipex.net>,
|  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> 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).
|
|Nick why do you say this? Have you run into an Ada 95
|compiler where the types did not match? If so, it would
|be a clear bug!

Re: identify floating-point types

[bglbv]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> Well, with some languages (notably C and C++), on some machines, there are
> multiple parameter (and memory format) conventions.  But, I have to admit, I
> think, in practice, Fortran conventions tend to be pretty consistent, for
> any one particular architecture.  

Except on Microsoft Windows platforms, where there seem to be as many
conventions as compiler vendors (except perhaps where DLLs are involved).

robert_dewar@my-dejanews.com wroteL
> |In article <7cpk9t$s5o$1@plug.news.pipex.net>,
> |  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> |> 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).
> |
> |Nick why do you say this? Have you run into an Ada 95
> |compiler where the types did not match? If so, it would
> |be a clear bug!

The types only have to match if the Fortran implementation used is
among those officially supported by the Ada implementation. There is
no requirement in the Ada standard for a compiler to interface
correctly with all conceivable Fortrans on the same platform.
Nick's advice to check the documentation and see if that combination
of compilers is supported is spot on. *If it is supported*, then
the types should of course match.