Re: Interfacing Ada with C

[sjw <simon.j.wright@mac.com>]

On Aug 5, 2:23 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <b7f5edce-124d-4b91-82f2-e9793d39a...@x25g2000yqj.googlegroups.com>,
>  Ada novice <po...@gmx.us> wrote:
>
>
>
> > 2. a real orthogonal matrix. Such a matrix gives all eigenvalues of
> > unit modulus. I tested the case from
> >http://en.wikipedia.org/wiki/Orthogonal_matrix.
> > In Matlab,
>
> >    eig([0, -0.8, -0.6; 0.8, -0.36, 0.48; 0.6, 0.48, -0.64])
>
> >    gives the eigenvalues as 0 + 1i, 0 - 1i and -1.
>
> >    Using your Ada code gives:
>
> >    -1.78814E-08  1.00000E+00
> >    -8.72890E-09 -1.00000E+00
> >    -1.00000E+00  0.00000E+00
>
> > Does the Blas code work with Fortran double-precision? In the above,
> > Matlab with double (15 digits precision). I don't see you using the
> > type Long_Float in the Ada code. I don't know how many digits are
> > being passed from the Fortran result to Ada. Maybe this is causing the
> > discrepancy between the expected results (all eigenvalues of modulus
> > one) and the output in Ada.
>
> Using these declarations in test_extensions.adb:
>
>    subtype My_Float is Long_Float;
>
>    Input : constant Complex_Matrix
>      := (((0.0, 0.0), (-0.8,  0.0),  -0.6,  0.0)),
>          ((0.8, 0.0), (-0.36, 0.0),  (0.48, 0.0)),
>          ((0.6, 0.0),  (0.48, 0.0), (-0.64, 0.0)));
>
> I get this result:
>
> ./test_extensions
>  0.00000000000000E+00  1.00000000000000E+00
> -2.77555756156289E-17 -1.00000000000000E+00
> -1.00000000000000E+00  0.00000000000000E+00

The reason for the 'subtype My_Float is Float;' is to make it easy to
change the type in use, for experimentation. You can certainly use
Fortran double precision, equivalent to the GNAT Ada Long_Float.

Although LAPACK/BLAS (at 3.2.2 anyway) allow you to build with
extended precision (80-bit floats, GNAT Long_Long_Float if on x86
hardware) GNAT's implementation of Generic * Arrays assumes the worst
case, ie BLAS/LAPACK only available in single & double precision; and
if the type in use (My_Float in my test case) doesn't match Fortran
single or double precision it converts to double precision, makes the
call, then converts back. I think this deserves a warning at the least
if the precision of the result doesn't match the precision of the base
type.

The Extensions code makes the same transformations as GNAT's.