From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a40f6d312191b68e,start X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.181.140 with SMTP id by12mr16239494qab.0.1356634094805; Thu, 27 Dec 2012 10:48:14 -0800 (PST) Received: by 10.49.38.194 with SMTP id i2mr4789189qek.30.1356634094784; Thu, 27 Dec 2012 10:48:14 -0800 (PST) Path: k2ni3151qap.0!nntp.google.com!ee4no2593442qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 27 Dec 2012 10:48:14 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.229.206.178; posting-account=eLk0BgoAAAA-yA75xm1L7heSizMaESVg NNTP-Posting-Host: 71.229.206.178 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9242b176-7050-46f8-a65d-6091aa4b2de8@googlegroups.com> Subject: A thicker binding for Lapack From: jpwoodruff@gmail.com Injection-Date: Thu, 27 Dec 2012 18:48:14 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-12-27T10:48:14-08:00 List-Id: 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