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,859116256d0a7bc2 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.82.195 with SMTP id k3mr1321484pay.23.1344321503157; Mon, 06 Aug 2012 23:38:23 -0700 (PDT) Path: g9ni2850446pbo.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ctu-peer!news.nctu.edu.tw!goblin2!goblin.stu.neva.ru!news.internetdienste.de!news.tu-darmstadt.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: basic question on nested packages Date: Mon, 30 Jul 2012 02:05:04 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 X-Trace: individual.net M2xx519wy9QoE0xRjVqLYgSkbPIE+PETtNmbyJ6pJiX6Jwir4aVmYq1STBGPVRHBXw Cancel-Lock: sha1:KNmJ1vEM3CRqqAKX1hh9MoatPlk= 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-07-30T02:05:04+03:00 List-Id: On 12-07-29 04:19 , Nasser M. Abbasi wrote: > On 7/28/2012 8:34 AM, Niklas Holsti wrote: > >> >> In other words, while this classification of LAPACK subroutines no doubt >> makes it easier to understand and learn to use LAPACK, I still don't see >> why it would be good to embody this logical classification as a package >> hierarchy. > > I see what you mean and I understand it. It will indeed make it simpler > to use if there is only one package to include so one does not > have to figure which child to include. > > I looked more at the packages, and it will be possible to put all in > one lapack package. I guess if someone wanted to find which function > belong to which category, they can always look at the original lapack > web site for that. The declarations in the single package can be divided into a text section for each category, with comment headings separating the sections and explaining what the categories mean. That would serve the pedagogical purpose without introducting more packages. > I think though, the large size is due to that each function is broken to 4 > functions (one for each flavor of the input type (single, double, > complex single, > complex double). In addition the same function is further broken into based > on the storage of the matrix itself (normal, symmetric, banded, etc...) > > So, that is why there are so many functions and code. i.e. for the same > one function, there will be may be 30 functions (all different by > permutations > of the starting letters of the name of the function and/or the ending > letter) > but they all do the same thing pretty much. This could be a more logical reason for having some nested or child packages in the Ada binding: there could be a nested or child package for each elementary type, with a further nested or child package for each storage form. For example, the package lapack.single.symmetric could hold the subprograms for operations on symmetric matrices of single-precision numbers. The naming of the operations would be changed correspondingly so that the Fortran subroutine SGEBRD, for example, would become lapack.single.general.BRD. This scheme could make it easy to change a client from single-precision to double precision, for example. The single precision version would do this: with lapack.single.general; use lapack.single.general; ... begin BRD (...); end; The double-precision version would change just the context clauses to with lapack.double.general; use lapack.double.general; The call to BRD would be unchanged, although it would now call a different Fortran subroutine. An alternative would be to just change the operation names for Ada to omit the "type and format" letters and instead rely on overloading by parameter type to select the intended subprogram, while keeping all declarations in a single "lapack" package. The client would do: with lapack; ... declare matrix : lapack.; begin lapack.BRD (... matrix, ... ); end; The Ada compiler would pick the correct "BRD" subprogram for this matrix type, e.g. SGEBRD if the matrix type is a general matrix of single-precision numbers. > Well, they did not have generics in Fortran when they wrote Lapack! So the > above was the only way to do what they did using Fortran at the time. Generics could have helped a bit, for those operations where the algorithm (source code) is the same for different types. But in numerical SW one often has to use different algorithms for different precisions or matrix formats, and then generics (in the Ada style, at least) do not help. Overloading by parameter/result types could have kept the name-space smaller, but I think it would still have been necessary to implement most subprograms separately for each precision and matrix format, because the algorithms are different. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .