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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a83584e000bc28fa X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.154.76 with SMTP id n12mr965716bkw.1.1345362627873; Sun, 19 Aug 2012 00:50:27 -0700 (PDT) Received: by 10.180.98.234 with SMTP id el10mr1322862wib.3.1345362627436; Sun, 19 Aug 2012 00:50:27 -0700 (PDT) Path: m12ni114323bkm.0!nntp.google.com!news1.google.com!7no24931011wig.0!news-out.google.com!q11ni201070638wiw.1!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: ada lapack Date: Sun, 19 Aug 2012 10:50:25 +0300 Organization: Tidorum Ltd Message-ID: References: <12f929e9-eea3-4dc9-b10d-71e4f5732e0d@googlegroups.com> <615dd222-9c8b-4878-94f7-b1cd4792bd3e@googlegroups.com> <36bc4009-6240-4797-991c-b72ec290cedc@googlegroups.com> <12606f3f-aec1-489c-8325-18e13007b6a6@googlegroups.com> <11959826-e12e-4455-b9d9-1ac4dcaf2952@googlegroups.com> <3bdbf14a-52ff-4b72-9e7b-42b543538959@googlegroups.com> <5865849c-3897-4be5-8d54-1de2e1acc3a7@googlegroups.com> <781001a0-3a99-40ac-bc5b-c8337124b29b@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net 6Ld0nAsM9Q4vDsoobw5HCQigCPuJz39/jTKK+7UuO81tXYqWx9aXoj4M7uw/MuPABD Cancel-Lock: sha1:HXmmdHpEaHFP1VKZpy8MhZEjmA8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-19T10:50:25+03:00 List-Id: On 12-08-19 02:40 , Nasser M. Abbasi wrote: > On 8/18/2012 6:16 PM, Niklas Holsti wrote: >> On 12-08-19 01:51 , Nasser M. Abbasi wrote: >>> On 8/18/2012 3:45 PM, Niklas Holsti wrote: >>> >>>> >>>> I wonder why Ada_Lapack needs convention-Fortran matrices, when it does >>>> not use any Fortran code. >>> >>> I assumed all along this is becuase Fortran matrix is column major >>> order for storing the memory layout for the matrix. C uses row >>> major, and I assumed Ada does also. Fortran and Matlab uses Column >>> major. >> >> All true (well, I don't know about Matlab, but I can believe you). >> >> If Ada code passes matrices to Fortran code, the Fortran layout must be >> used, since the Fortran code assumes it. (Or else the Fortran code sees >> the matrix as transposed.) >> >> But the layout of a matrix in pure Ada code does not matter (except, >> possibly, for execution time) if the code accesses the matrix in the >> usual way with indices. The layout matters only if the matrix is >> accessed in some nasty way, such as by using overlays (for X'address use >> ...) as is now done in Ada_Lapack. >> > > > humm... but Fortran pre-compiled binary code will send back a matrix > data to Ada. It is 2-ways. So, the binding is telling the compiler, > or the rtl to rearrange the matrix data from lapack so that it is > in row major so that when it is used in Ada, it is in the correct > memory layout for Ada. Ada_Lapack is entirely in Ada. It does not call any Fortran code. The only reason for using Fortran layout is to let the Ada translation access matrix rows and matrix columns using the same "recasting" tricks as in the original Fortran code. That is a hack, but it is also a conservative translation approach that is defensible if the result is good for one's needs. But it has the drawback that the Ada standard matrix types cannot be used, which means that their operations (like "+") are not automatically available. I think it would be possible to use the recasting tricks for matrices in the Ada layout, but one would have to change the strides in several places in the code -- that is, where the code now accesses columns with stride 1, and rows with stride "column length", this would have to be swapped so that rows are accessed with stride 1, and columns with stride "row length". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .