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,31c8255073b2d349 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!d8g2000yqf.googlegroups.com!not-for-mail From: jonathan Newsgroups: comp.lang.ada Subject: Re: ANN: Ada 2005 Math Extensions, 20100901 release Date: Tue, 7 Sep 2010 08:51:13 -0700 (PDT) Organization: http://groups.google.com Message-ID: <50d9fde1-c17c-4899-ada9-8bf650dbf708@d8g2000yqf.googlegroups.com> References: <889c1e51-cd27-4e7e-b5ae-b9e2c1c5b644@u6g2000yqh.googlegroups.com> <5c42e8bf-b12d-4c92-9eb6-5b056832352a@l20g2000yqe.googlegroups.com> <513c30f4-55f7-49de-8b17-9f932e726f36@d8g2000yqf.googlegroups.com> <6515d38b-b0c3-436d-81b0-0e117fb8da56@k10g2000yqa.googlegroups.com> NNTP-Posting-Host: 143.117.23.233 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1283874675 19828 127.0.0.1 (7 Sep 2010 15:51:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Sep 2010 15:51:15 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d8g2000yqf.googlegroups.com; posting-host=143.117.23.233; posting-account=Jzt5lQoAAAB4PhTgRLOPGuTLd_K1LY-C User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.19) Gecko/2010072022 Iceweasel/3.0.6 (Debian-3.0.6-3),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:13967 Date: 2010-09-07T08:51:13-07:00 List-Id: On Sep 7, 1:56=A0pm, sjw wrote: > On Sep 5, 1:32=A0am, jonathan wrote: > > > > > On Sep 4, 12:12=A0pm, Ada novice wrote: > > > > I tried compiling test_extensions.adb but I get an error message: > > > > =A0 =A0 20. with Ada.Numerics.Generic_Complex_Arrays; > > > =A0 =A0 21. with Ada.Numerics.Generic_Arrays; > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0| > > > =A0 =A0 =A0 =A0 >>> "Ada.Numerics.Generic_Arrays" is not a predefined= library > > > unit > > > > ... > > > YC > > > Don't worry, I got the same error message, knew I would > > not be smart enough to fix it, and just replaced all > > the dots with underscores. Now my version is named > > ada_numerics_generic_arrays.adb > > > I got around to attaching my suite of test matrices to > > the new LAPACK binding. =A0A few rambling observations.. > > First the good news is that the binding seems to work > > the way it's supposed to .. no problems to report there. > > This is good news because it is much easier to fill in > > missing LAPACK routines now that Simon has shown us how > > to do it. In particular I seem to recall that you (YC) > > requested a routine for generalized Eigen systems: > > =A0 =A0A*v =3D lambda*B*v > > for matrices A and B. That should be easy to add to > > the present interface. The not-so-good news is that I > > tested Lapack's eigendecomposition for real general > > (non-symmetric) matrices, dgeev, and I was surprized > > to see it fail catastrophically on 3 > > or 4 matrices in the test suite, and perform poorly > > on another 7 or 8. =A0It worked fine on small matrices > > (N x N =3D 16 x 16) but degraded rapidly for larger N, > > so I don't think I am misinterpreting the test results. > > I see similar behaviour (can't go up to 787 on this Mac, or rather I > haven't tried too hard) but it starts showing up at 64x64 and is > obvious at 128x128. > > Your test says that Eig.Eigensystem overwrites the input matrix -- it > doesn't (of course, at the cost of another on-stack copy :-) My mistake. I copied the warning from Peters_Eigen and from the original dgeev routine, both of which do overwrite A. Other comments were also foolishly retained from the original Peters_Eigen_tst_1, so I have revised the file. > Also, I now find myself confused about pragma Convention (Fortran) -- > my code expects (effectively) pragma Convention (Ada) for matrices, > and commenting-out your pragma made no difference to the results!!! The pragma Convention was also from Peters_Eigen_tst_1 where it did seem to matter. I left it in numerics_tst_1 so that an interested user can toggle it on and off to see if it matters .. it's easy to forget about this option, and in some programs it can amount to a factor of 2 in running time. > My plan, not being a mathematician and not having any immediate need > for matrix manipulations myself, was to implement interfaces to > existing libraries, specifically LAPACK 'because it's there', on the > assumption that they would be reasonably good (both in performance and > accuracy). If that's not so, a new horizon beckons ... Lapack is the gold standard in this business. The reason I was grateful that you wrote this for us is that I knew I would never be interested in writing my own versions of 95% of the routines in Lapack. Of the matrices that dgeev.f failed on, most are so pathological and badly scaled that I doubt anything of the sort would occur in a real application, and I doubt anyone would care much if dgeev.f failed on them. There was one interesting exception to this rule: Lower_Integers, which is (nearly) lower triangular, with the integers 1, 2, 3... on the diagonal. This is (nearly) the easiest matrix in the test suite. Don't know what went wrong with dgeev here, but in this case the failure was appalling. I suspect that making an eigensolver that never fails is considered a holy grail problem in numerical linear algebra. (Come to think of it, I wonder if anyone can break Peters_Eigen with its Jacobi preconditioner enabled .. or disabled for that matter. Let them try;-) Mainly I wrote numerics_tst_1.adb to show how to use the new LAPACK binding in a significant program. I thought it might make the new software easier to use and understand. Well it helped me anyway! J.