comp.lang.ada
 help / color / mirror / Atom feed
From: jpwoodruff@gmail.com
Subject: A thicker binding for Lapack
Date: Thu, 27 Dec 2012 10:48:14 -0800 (PST)
Date: 2012-12-27T10:48:14-08:00	[thread overview]
Message-ID: <9242b176-7050-46f8-a65d-6091aa4b2de8@googlegroups.com> (raw)

There is a complete thin binding for lapack available which was
evidently started by Wasu Chaopanon in about 1996 and was recently
finished by Nasser Abbasi.  There about 1000 subroutines; their
parameter signatures exactly translate the Fortran, and each procedure
is Pragma Imported.

I've been considering adding value to that binding to address two
perceived problems:

The specification involving the integer index used for matrix types is
inconsistent between the binding and Ada.Numerics.Generic_Real_Arrays.
The binding declares that type because the user's code must comply
with Fortran's integer.  The Ada compiler is obliged to use that same
type.  Unfortunately Generic_Real_Arrays uses the base type integer
for index, so there is no expectation that the representation would be
the same as Fortran-compiled library.

Another issue to resolve is that lapack, being Fortran, defines
column-major storage while Ada is row-major.  Parameters passing
between these two conventions evidently must be transposed.

I think I have a technique for interoperating with the Ada.Numerics
types.  My plan involves "wrapping" the lapack routines in a layer
that converts types and transposes matrices.

Here is a typical procedure specification as translated directly from
the fortran, with my transformation to Ada standard types.

   procedure SGESV
     (N    : Natural;
      NRHS : Natural;
      A    : in out Real_Arrays.Real_Matrix;   -- instance of Generic_
      LDA  : Natural ;
      IPIV : out Integer_Vector;
      B    : in out Real_Arrays.Real_Matrix;
      LDB  : Natural ;
      INFO : out Integer) ;

The math requirements for this procedure are very much like the
"Solve" that was discussed in a recent thread.

   -- function Solve (A : Real_Matrix; X : Real_Vector) return
   -- Real_Vector;

The B parameter in sgesv resembles X in the "Why X as argument name?"
discussion.  I am trying to make the lapack item as serviceable as the
gnat standard item.

My trials at maintaining parameter definitions that echo the Fortran
binding have led only to grief.  The integer inputs N, NRHS, LDA, LDB
make precious little sense, considering the transposition of the
matrices that takes place inside the body of procedure sgesv.

After several drafts I'm thinking that a thick binding might look
like this:

   procedure SGESV
      (A   : in out Real_Arrays.Real_Matrix;
      IPIV : out Integer_Vector;
      B    : in out Real_Arrays.Real_Matrix;
      INFO : out Integer) ;

Programming with Ada attributes seems to clarify the relations between
the several parameters.  Now I think that the integer parameters will
be computed inside the body of the overlay procedure.  Still working
on the details.

Guided by the spiral model I'll try a couple examples.  Later if there
is a benefit to Ada programmers interested in numeric analysis I'll
address the scale of the massive lapack library.

Suggestions are welcome!

John



             reply	other threads:[~2012-12-27 18:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-27 18:48 jpwoodruff [this message]
2012-12-27 19:18 ` A thicker binding for Lapack Shark8
2012-12-29 18:36   ` jpwoodruff
2012-12-29 19:59     ` Simon Wright
2012-12-30 18:05       ` jpwoodruff
2012-12-30 19:41         ` Simon Wright
2013-01-01  0:24           ` jpwoodruff
2012-12-27 20:37 ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox