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
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.224.180.141 with SMTP id bu13mr19411312qab.2.1356806161418;
        Sat, 29 Dec 2012 10:36:01 -0800 (PST)
Received: by 10.49.116.115 with SMTP id jv19mr5654271qeb.21.1356806161394;
 Sat, 29 Dec 2012 10:36:01 -0800 (PST)
Path: 
 k2ni3151qap.0!nntp.google.com!ee4no4296655qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 29 Dec 2012 10:36:01 -0800 (PST)
In-Reply-To: <0bc6a851-8eea-4279-b616-3f7895049d4b@googlegroups.com>
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
References: <9242b176-7050-46f8-a65d-6091aa4b2de8@googlegroups.com>
 <0bc6a851-8eea-4279-b616-3f7895049d4b@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6638b519-7fad-4908-9b80-3a43e6a0b8f7@googlegroups.com>
Subject: Re: A thicker binding for Lapack
From: jpwoodruff@gmail.com
Injection-Date: Sat, 29 Dec 2012 18:36:01 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2012-12-29T10:36:01-08:00
List-Id: <comp.lang.ada>

On Thursday, December 27, 2012 12:18:09 PM UTC-7, Shark8 wrote:
> On Thursday, December 27, 2012 12:48:14 PM UTC-6, jpwoo...@gmail.com wrote:
> 
> >
> 
> > 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.
> 
> 
> 
> This is a non-issue; Ada allows for the specification of row- or column-major ordering via the Convention pragma (or aspect).
> 
The use case I'm working on is to allow a mathematical program that
already uses matrices to be enhanced with lapack operators on the same
type of operand.  

If I'm not mistaken, pragma convention will affect matrices that are
used on the lapack interface, but other matrix types in the program
remain row-wise.  

This is the inconsistency I'm working to avoid unless every matrix
type is conventioned, and it's not clear how to catch them all.

The alignment is visible to the user through (at least) the program's
I/O.

Conclusion:   transpose appears necessary.

John