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=2.0 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,
	REPLYTO_WITHOUT_TO_CC 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.224.180.205 with SMTP id bv13mr11589603qab.8.1343789896654;
        Tue, 31 Jul 2012 19:58:16 -0700 (PDT)
Received: by 10.68.228.227 with SMTP id sl3mr3771235pbc.5.1343789455914;
        Tue, 31 Jul 2012 19:50:55 -0700 (PDT)
Path: 
 a15ni14729222qag.0!nntp.google.com!h9no2122630pbv.0!news-out.google.com!g9ni9632822pbo.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: "Nasser M. Abbasi" <nma@12000.org>
Newsgroups: comp.lang.ada
Subject: Re: basic question on nested packages
Date: Sat, 28 Jul 2012 20:19:58 -0500
Organization: Aioe.org NNTP Server
Message-ID: <jv2349$bfb$1@speranza.aioe.org>
References: <juvlur$5du$1@speranza.aioe.org> <a7i3ndF8h9U1@mid.individual.net>
 <jv0na2$b3p$1@speranza.aioe.org> <a7i83sF9bpU1@mid.individual.net>
Reply-To: nma@12000.org
NNTP-Posting-Host: 9ii5QNw33OfeoTzEH8w9ug.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-07-28T20:19:58-05:00
List-Id: <comp.lang.ada>

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.

I'll see if I can make the changes to use one package since all the
other packages do is just add more API's. Nothing more.  It will be
easier to use this way for a client. (There are so many functions in
Lapack, it is scary to think how long it took to write all of this and
do it right. I remember reading somewhere (can't find the link now) that
lapack is about 700,000 lines of Fortran code.

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.

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.

--Nasser