ANN: Ada 2005 Math Extensions, 20100901 release
Simon Wright
(https://sourceforge.net/projects/gnat-math-extn/) on SourceForge:
20100901
An additional overloaded procedure Eigensystem returns the
complex eigenvalues and eigenvectors of a non-symmetric real
matrix.
This release has been tested on Mac OS X (GNAT GPL 2010, GCC 4.5.0) and
on Debian 5, lenny (GCC 4.3.2).
Ada novice
YC
jonathan
> Thanks Simon. I shall do some testing.
>
> YC
Same here, much appreciated. Will try to find time
in a few days to do testing.
I did a quick test with good results. I still can't
get gnat GPL 2010 to link to lapack tho.. get the famous
../x86_64-pc-linux-gnu/4.3.6/ld: cannot find -lgnalasup
error message. This has been discussed on c.l.a
for years, but I won't have time to look into it.
Fortunately, the gnat that comes with debian lenny
still works fine.
J.
John B. Matthews
<889c1e51-cd27-4e7e...@u6g2000yqh.googlegroups.com>,
jonathan <john...@googlemail.com> wrote:
> On Sep 2, 4:40 pm, Ada novice <ycalleecha...@gmx.com> wrote:
> > Thanks Simon. I shall do some testing.
>
> Same here, much appreciated. Will try to find time
> in a few days to do testing.
>
> I did a quick test with good results. I still can't
> get gnat GPL 2010 to link to lapack tho.. get the famous
>
> ../x86_64-pc-linux-gnu/4.3.6/ld: cannot find -lgnalasup
>
> error message. This has been discussed on c.l.a
> for years, but I won't have time to look into it.
>
> Fortunately, the gnat that comes with debian lenny
> still works fine.
For future reference, here is the patch:
<http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01623.html>
The compiler options from ada_math_build.gpr should work, e.g. gnatmake
-a or gcc -c -gnatpg. Finally, copy the .ali and .o to your Ada library
path, `gnatls -v`.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Simon Wright
> For future reference, here is the patch:
>
> <http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01623.html>
Interesting. On Mac OS X, GNAT GPL 2010 i-forbla.adb contains
package body Interfaces.Fortran.BLAS is
pragma Linker_Options ("-lgnala");
pragma Linker_Options ("-lm");
pragma Linker_Options ("-Wl,-framework,vecLib");
end Interfaces.Fortran.BLAS;
> The compiler options from ada_math_build.gpr should work,
> e.g. gnatmake -a or gcc -c -gnatpg. Finally, copy the .ali and .o to
> your Ada library path, `gnatls -v`.
I don't see why you'd do this 'by hand' rather than letting
ada_math_build.gpr do the heavy lifting?
If you do do this, (a) make sure the .ali is read-only, (b) copy
ada-numerics-generic_arrays.ad[bs] too (to the source search path, of
course).
I'm having 4th or 5th thoughts about package naming. Perhaps I should
make it Ada_Numerics.Generic_Arrays? That way future compiler releases
won't get sniffy about this non-ARM package. OTOH, it isn't broken now
...
John B. Matthews
Simon Wright <si...@pushface.org> wrote:
> "John B. Matthews" <nos...@nospam.invalid> writes:
>
> > For future reference, here is the patch:
> >
> > <http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01623.html>
>
> Interesting. On Mac OS X, GNAT GPL 2010 i-forbla.adb contains
>
> package body Interfaces.Fortran.BLAS is
> pragma Linker_Options ("-lgnala");
> pragma Linker_Options ("-lm");
> pragma Linker_Options ("-Wl,-framework,vecLib");
> end Interfaces.Fortran.BLAS;
>
> > The compiler options from ada_math_build.gpr should work, e.g.
> > gnatmake -a or gcc -c -gnatpg. Finally, copy the .ali and .o to
> > your Ada library path, `gnatls -v`.
>
> I don't see why you'd do this 'by hand' rather than letting
> ada_math_build.gpr do the heavy lifting?
Good point. I got used to doing it manually while nursing GNAT 4.3.4.
I'm slowly coming to terms with GPS, but it won't stay off my lawn. :-)
> If you do do this, (a) make sure the .ali is read-only, (b) copy
> ada-numerics-generic_arrays.ad[bs] too (to the source search path, of
> course).
>
> I'm having 4th or 5th thoughts about package naming. Perhaps I should
> make it Ada_Numerics.Generic_Arrays? That way future compiler
> releases won't get sniffy about this non-ARM package. OTOH, it isn't
> broken now ...
Difficult call. I implemented Ada.Numerics.Generic_Complex_Arrays.
Generic_Roots according to the (proposed) specification, but I don't
know how hard it would be to move.
jonathan
> In article
> <889c1e51-cd27-4e7e-b5ae-b9e2c1c5b...@u6g2000yqh.googlegroups.com>,
Thanks .. worked great.
J.
Ada novice
use aunit. So I've stripped away the files that I "don't" need and
ended up with these 3 files in a new folder:
ada-numerics-generic_arrays.ads
ada-numerics-generic_arrays.adb
test_extensions.adb
I tried compiling test_extensions.adb but I get an error message:
20. with Ada.Numerics.Generic_Complex_Arrays;
21. with Ada.Numerics.Generic_Arrays;
|
>>> "Ada.Numerics.Generic_Arrays" is not a predefined library
unit
22.
23. procedure Test_Extensions is
24.
I'm not proud of course that I don't understand how to use Aunit, but
can I just separate the three files as I did above and try to run
test_extensions.adb?
Thanks for your kind help.
YC
Simon Wright
> I'm not proud of course that I don't understand how to use Aunit, but
> can I just separate the three files as I did above and try to run
> test_extensions.adb?
With some difficulty.
It'd be easier to keep the directory structure as-distributed and
1) go to the test directory
2) gnatmake -p -P test_extensions.gpr
This way the extra compiler options needed to build what look like
components of the standard Ada library will be automatically supplied by
src/ada_math_build.gpr.
This is what it looks like for me (it will be different for you, since
you are on Windows (I think), and in any case your directory structures
won't be the same):
$ cd test
$ gnatmake -p -P test_extensions.gpr
object directory "/Users/simon/gnat-math-extn/gnat-math-extn-20100901/src/.build" created for project ada_math_build
library directory "/Users/simon/gnat-math-extn/gnat-math-extn-20100901/src/../lib" created for project ada_math_build
object directory "/Users/simon/gnat-math-extn/gnat-math-extn-20100901/test/.build" created for project test_extensions
gcc -c -g -gnatpg -gnatqQ -gnatafo -gnatwaL -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/gnat-math-extn-20100901/src/ada-numerics-generic_arrays.adb
gcc -c -g -gnatqQ -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/gnat-math-extn-20100901/test/test_extensions.adb
building static library for project ada_math_build
ar cr /Users/simon/gnat-math-extn/gnat-math-extn-20100901/lib/libada_math.a /Users/simon/gnat-math-extn/gnat-math-extn-20100901/src/.build/ada-numerics-generic_arrays.o
ranlib /Users/simon/gnat-math-extn/gnat-math-extn-20100901/lib/libada_math.a
gnatbind -E -I- -x /Users/simon/gnat-math-extn/gnat-math-extn-20100901/test/.build/test_extensions.ali
gnatlink /Users/simon/gnat-math-extn/gnat-math-extn-20100901/test/.build/test_extensions.ali -g -L/Users/simon/gnat-math-extn/gnat-math-extn-20100901/lib/ -lada_math -Wl,-rpath,/opt/gnat-gpl-2010-x86_64/lib/gcc/x86_64-apple-darwin9.6.0/4.3.6/adalib/ -o /Users/simon/gnat-math-extn/gnat-math-extn-20100901/test/test_extensions
Simon Wright
> It'd be easier to keep the directory structure as-distributed and
>
> 1) go to the test directory
>
> 2) gnatmake -p -P test_extensions.gpr
See also the README in the distribution (if it isn't clear,
contributions very welcome!)
Ada novice
> Ada novice <ycalleecha...@gmx.com> writes:
> > I'm not proud of course that I don't understand how to use Aunit, but
> > can I just separate the three files as I did above and try to run
> > test_extensions.adb?
>
> With some difficulty.
>
Thanks. I did what you asked. Afterwards I opened test_extensions.gpr
in GPS and could compile the main file test_extensions.adb and get the
results. I see that if I open tests.gpr, I can't compile the file
tests-main.adb. So I guess that I should stick to test_extensions.gpr
and test_extensions.adb.
Thanks.
YC
Simon Wright
> Thanks. I did what you asked. Afterwards I opened test_extensions.gpr
> in GPS and could compile the main file test_extensions.adb and get the
> results. I see that if I open tests.gpr, I can't compile the file
> tests-main.adb. So I guess that I should stick to test_extensions.gpr
> and test_extensions.adb.
When building your own app, test_extensions.* would be a better place to
start from.
jonathan
> I tried compiling test_extensions.adb but I get an error message:
>
> 20. with Ada.Numerics.Generic_Complex_Arrays;
> 21. with Ada.Numerics.Generic_Arrays;
> |
> >>> "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. A 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:
A*v = 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. It worked fine on small matrices
(N x N = 16 x 16) but degraded rapidly for larger N,
so I don't think I am misinterpreting the test results.
This was so surprizing I dusted off an Ada translation of
the ancient EISPACK hqr2.f I did a while ago. It never
worked very well either, so I decided to throw out the
EISPACK Hessenberg reduction and replace it with one based
on Givens rotations. Now it works correctly on all the
matrices in the test suite. I've tested it up to
2901 x 2901 matrices without problem (it took mere 18.3
hours on 60 matrices). I've always liked Givens rotations!
The package is called Peters_Eigen, (after the original
author) and I put it in a public directory:
http://web.am.qub.ac.uk/users/j.parker/miscellany/eig_stuff/
It's quickly written and lightly tested, but you may want
to play with it... instructions for compiling the test/
demo routine peters_eigen_test_1.adb with gnatmake on the
command line are in the README ... no LAPACK, very easy.
I did a test on 787 x 787 matrices comparing LAPACK with
Peters_Eigen. Results are in the file bench1.txt in the
public directory. The LAPACK test procedure is identical
to the Peters_Eigen test procedure. The LAPACK run
took 550 seconds on the 60 matrices. Peters_Eigen took
676 seconds.
J.
Ada novice
> On Sep 4, 12:12 pm, Ada novice <ycalleecha...@gmx.com> wrote:
>
> > I tried compiling test_extensions.adb but I get an error message:
>
> > 20. with Ada.Numerics.Generic_Complex_Arrays;
> > 21. with Ada.Numerics.Generic_Arrays;
> > |
> > >>> "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
Did you change the occurrences of the dots in the files :
ada-numerics-generic_arrays.ad(b,s)?
>
> I got around to attaching my suite of test matrices to
> the new LAPACK binding.
This is exciting news.
A 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:
> A*v = lambda*B*v
> for matrices A and B. That should be easy to add to
> the present interface.
Yes I did propose that earlier.
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. It worked fine on small matrices
> (N x N = 16 x 16) but degraded rapidly for larger N,
> so I don't think I am misinterpreting the test results.
> This was so surprizing I dusted off an Ada translation of
> the ancient EISPACK hqr2.f I did a while ago. It never
> worked very well either, so I decided to throw out the
> EISPACK Hessenberg reduction and replace it with one based
> on Givens rotations. Now it works correctly on all the
> matrices in the test suite. I've tested it up to
> 2901 x 2901 matrices without problem (it took mere 18.3
> hours on 60 matrices). I've always liked Givens rotations!
> The package is called Peters_Eigen, (after the original
> author) and I put it in a public directory:
I'm not currently working with so large matrices. It was interesting
to
read how large matrices needed different methods. On a related note,
in
Finite Element Analysis (FEM), usually we end up with sparse matrices.
Does Ada makes provision for such type of matrices? I didn't come
across
other sources mentioning sparse matrices except in Feldman's Software
Construction and Data Structures with Ada 95 textbook.
>
> http://web.am.qub.ac.uk/users/j.parker/miscellany/eig_stuff/
>
> It's quickly written and lightly tested, but you may want
> to play with it... instructions for compiling the test/
> demo routine peters_eigen_test_1.adb with gnatmake on the
> command line are in the README ... no LAPACK, very easy.
> I did a test on 787 x 787 matrices comparing LAPACK with
> Peters_Eigen. Results are in the file bench1.txt in the
> public directory. The LAPACK test procedure is identical
> to the Peters_Eigen test procedure. The LAPACK run
> took 550 seconds on the 60 matrices. Peters_Eigen took
> 676 seconds.
>
> J.
Thanks for your efforts.
cheers
YC
Simon Wright
> 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 wish I understood what it is I didn't say in the README that led you
both to get into all this grief!
It says
"The software unpacks into a directory structure of the form
gnat-math-extn-YYYYMMDD
/src contains the library code
/test contains an installation verification program and unit tests.
Go to the test/ directory. If on a Unix-based system, run
$ gnatmake -p -P test_extensions
$ ./test_extensions
or if on Windows,
> gnatmake -p -P test_extensions
> test_extensions
This should output the results of a simple set of tests.
[At some future release, we will list the expected output]
As a side-effect, it builds a static library for use in your own
programs.
In order to use this library within your own code, you need to use a
GPR referencing the extensions' GPR, "ada_math_build" [This name is
subject to change]. Either
* say 'with "ada_math_build";' and include
/where/ever/gnat-math-extn-YYYYMMDD/src in your ADA_PROJECTS_PATH
environment variable; or
* say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
(this path can be relative, if you like)."
jonathan
> jonathan <johns...@googlemail.com> writes:
> > 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 wish I understood what it is I didn't say in the README that led you
> both to get into all this grief!
The tests worked without a hitch on my Debian standard GNAT
installation
using test_extensions.gpr. Still can't get them to compile on GNAT
GPL 2010 -
get the dreaded "ld: cannot find -lgnalasup" message, which I thought
I
got rid of a long time ago. I don't use .gpr files, so I don't want to
spend
any time on it ... changing 2 file names is a grief-free exercise.
J.
Ada novice
> jonathan <johns...@googlemail.com> writes:
> > 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 wish I understood what it is I didn't say in the README that led you
> both to get into all this grief!
Well, I didn't read the README file for a start and I was trying to
strip away all files
that use AUnit. And I didn't keep your directory structure. Of course
this is my mistake.
> As a side-effect, it builds a static library for use in your own
> programs.
Can we include this library in GPS for use with our own codes? I try
to
include it as a library but I wasn't successful.
>
> In order to use this library within your own code, you need to use a
> GPR referencing the extensions' GPR, "ada_math_build" [This name is
> subject to change]. Either
>
> * say 'with "ada_math_build";' and include
> /where/ever/gnat-math-extn-YYYYMMDD/src in your ADA_PROJECTS_PATH
> environment variable; or
>
> * say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
> (this path can be relative, if you like)."
I tried the first method. Still, I am not sure what the
ADA_PROJECTS_PATH environment variable is. Can we customize it within
GPS itself?
Thanks a lot
YC
sjw
The message I'm (at last) getting from you and Jonathan is that I'm
being too clever by half! Will make a release ASAP with file naming
that doesn't require library/compiler magic, in other words just
include in your source tree as Jonathan did.
sjw
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 :-)
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!!!
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 ...
jonathan
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.
jonathan
> Did you change the occurrences of the dots in the files :
> ada-numerics-generic_arrays.ad(b,s)?
See the text in the public directory. It should answer your
question.
> On a related note, in
> Finite Element Analysis (FEM), usually we end up with sparse matrices.
> Does Ada makes provision for such type of matrices? I didn't come
> across
> other sources mentioning sparse matrices except in Feldman's Software
> Construction and Data Structures with Ada 95 textbook.
>
I notice that LAPACK has a lot of routines for banded matrices. If
banded is not good enough then there are probably as many different
specialize methods for dealing with sparse systems as there are
problems to solve ... I don't know of any Ada packages for sparse
systems.
J.
Nasser M. Abbasi
>I don't know of any Ada packages for sparse
> systems.
>
> J.
fyi;
If someone wants to do an Ada package for sparse matrices, it might be
worth looking at making a binding to sparskit written in Fortran:
http://en.wikipedia.org/wiki/SPARSKIT
--Nasser
Ada novice
> In order to use this library within your own code, you need to use a
> GPR referencing the extensions' GPR, "ada_math_build" [This name is
> subject to change]. Either
>
> * say 'with "ada_math_build";' and include
> /where/ever/gnat-math-extn-YYYYMMDD/src in your ADA_PROJECTS_PATH
> environment variable; or
>
> * say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
> (this path can be relative, if you like)."
I asked about this earlier but didn't get an answer. Hopefully,
someone will answer now. If I want to use the library with my own
code, then how do I proceed? I tried the first solution (from above)
but I don't know how to include /where/ever/gnat-math-extn-YYYYMMDD/
src in the ADA_PROJECTS_PATH environment variable.
As for the second solution, I understand that it can be either a / or
a \ depending whether it's Windows or Linux. I have Windows and I
tried /. I can't get this to work. And how do I put an absolute path?
The GNAT compiler expects an identifier after with and it finds " and
complains.
Thanks a lot...
AdaMagica
> > * say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
> > (this path can be relative, if you like)."
> The GNAT compiler expects an identifier after with and it finds " and
> complains.
This is the syntax you have to use in your GNAT project file to make
the library visible to the GNAT compiler.
In Ada source files, you just use the appropriate package name as
defined in the library.
Ada novice
Thanks. Yes I understand what you are saying, but I can't make it
work.
Finally, the solution that I came up with was to work directly in the
test_extensions.adb file and put my code in there.
Simon Wright
> On Sep 6, 9:49 pm, Simon Wright <si...@pushface.org> wrote:
>
>> In order to use this library within your own code, you need to use a
>> GPR referencing the extensions' GPR, "ada_math_build" [This name is
>> subject to change]. Either
>>
>> * say 'with "ada_math_build";' and include
>> /where/ever/gnat-math-extn-YYYYMMDD/src in your ADA_PROJECTS_PATH
>> environment variable; or
>>
>> * say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
>> (this path can be relative, if you like)."
>
> I asked about this earlier but didn't get an answer. Hopefully,
> someone will answer now. If I want to use the library with my own
> code, then how do I proceed? I tried the first solution (from above)
> but I don't know how to include /where/ever/gnat-math-extn-YYYYMMDD/
> src in the ADA_PROJECTS_PATH environment variable.
When I wrote "/where/ever/..." I was being guilty of being
Unix-centric. Sorry.
The equivalent on Windows would be "X:\where\ever\...", in other words a
full file path from the top level downwards ('absolute' path).
There's a reasonable-looking tutorial on Windows env vars at
http://www.chem.gla.ac.uk/~louis/software/faq/q1.html (select your
Windows version in the first paragraph).
> As for the second solution, I understand that it can be either a / or
> a \ depending whether it's Windows or Linux. I have Windows and I
> tried /. I can't get this to work. And how do I put an absolute path?
> The GNAT compiler expects an identifier after with and it finds " and
> complains.
As someone else said, GPRs are read by the gnatmake tool, not by the
compiler (I realise this is a hard distinction to make!).
gnatmake foo.adb -- compile the Ada source foo.adb
gnatmake -P foo.gpr -- read & obey the project file foo.gpr
Windows gnatmake is quite happy to read forward-slash or backward-, I'm
not so sure about Unix gnatmake.
You may find it easier to model your GPR on my test_extensions.gpr -
suppose that you've unpacked my package into C:\gnat-math-extn-20100911,
then your GPR would begin
with "C:\gnat-math-extn-20100911\src\ada_math_build";
project YC is
...
Ada novice
> Ada novice <ycalleecha...@gmx.com> writes:
> > On Sep 6, 9:49 pm, Simon Wright <si...@pushface.org> wrote:
>
> >> In order to use this library within your own code, you need to use a
> >> GPR referencing the extensions' GPR, "ada_math_build" [This name is
> >> subject to change]. Either
>
> >> * say 'with "ada_math_build";' and include
> >> /where/ever/gnat-math-extn-YYYYMMDD/src in your ADA_PROJECTS_PATH
> >> environment variable; or
>
> >> * say 'with "/where/ever/gnat-math-extn-YYYYMMDD/src/ada_math_build";'
> >> (this path can be relative, if you like)."
>
> > I asked about this earlier but didn't get an answer. Hopefully,
> > someone will answer now. If I want to use the library with my own
> > code, then how do I proceed? I tried the first solution (from above)
> > but I don't know how to include /where/ever/gnat-math-extn-YYYYMMDD/
> > src in the ADA_PROJECTS_PATH environment variable.
>
> When I wrote "/where/ever/..." I was being guilty of being
> Unix-centric. Sorry.
>
> The equivalent on Windows would be "X:\where\ever\...", in other words a
> full file path from the top level downwards ('absolute' path).
>
> Windows version in the first paragraph).
>
> > As for the second solution, I understand that it can be either a / or
> > a \ depending whether it's Windows or Linux. I have Windows and I
> > tried /. I can't get this to work. And how do I put an absolute path?
> > The GNAT compiler expects an identifier after with and it finds " and
> > complains.
>
> As someone else said, GPRs are read by the gnatmake tool, not by the
> compiler (I realise this is a hard distinction to make!).
>
> gnatmake foo.adb -- compile the Ada source foo.adb
> gnatmake -P foo.gpr -- read & obey the project file foo.gpr
>
> Windows gnatmake is quite happy to read forward-slash or backward-, I'm
> not so sure about Unix gnatmake.
>
> You may find it easier to model your GPR on my test_extensions.gpr -
> suppose that you've unpacked my package into C:\gnat-math-extn-20100911,
> then your GPR would begin
>
> with "C:\gnat-math-extn-20100911\src\ada_math_build";
> project YC is
> ...
Thanks for the explanations. I'm a little pressed in time right now
but I will look again in what you have written and tried again. As I
mentioned in my earlier message, the solution I came up with was to
put my piece of code in test_extensions.adb and remove parts of your
code that I don't need. This is "working" for me.
Yes I have read the test_extensions.gpr to understand the structure. I
will definitely have to spend some time with the gprbuild manual in
order to be at ease to handle these files and to be able to write gpr
files on my own.
cheers
Ada novice
Recently, I had to use the package in the computation of eigenvalues.
The code had to compute eigenvalues of a 4 X 4 non-symmetric matrix
90,000 times and the computations took only very few seconds....just
the time it takes for a yawn :)
cheers
YC
Simon Wright
Ada novice
> Thanks also due to the LAPACK, BLAS & AdaCore teams!
Yes indeed. This extension package will definitely be valuable for
many persons out there.
Nasser M. Abbasi
It build OK on windows, using:
g:\gnat-math-extn-20100901\test>gnatmake --version
GNATMAKE GPL 2009 (20090519)
When I tried it under cygwin,
$ uname -a
CYGWIN_NT-6.1-WOW64 me-PC 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
using:
$ gnatmake --version
GNATMAKE 4.3.4 20090804 (release) 1
Copyright (C) 1995-2007, Free Software Foundation, Inc.
$ gcc --version
gcc (GCC) 4.3.4 20090804 (release) 1
I get warning that libraries not supported:
$ gnatmake -p -P test_extensions
ada_math_build.gpr:17:25: warning: libraries are not supported on this
platform
gcc -c -g -gnatqQ -gnat05 -I- -gnatA /cygdrive/g/nabbasi/data/ada_re
lated/gnat-math-extn-20100901/test/test_extensions.adb
gcc -c -g -gnatpg -gnatqQ -gnatafo -gnatwaL -gnat05 -I- -gnatA /cygd
rive/g/nabbasi/data/ada_related/gnat-math-extn-20100901/src/ada-nume
rics-generic_arrays.adb
gnatbind -E -I- -x /cygdrive/g/nabbasi/data/ada_related/gnat-math-ex
tn-20100901/test/.build/test_extensions.ali
gnatlink /cygdrive/g/nabbasi/data/ada_related/gnat-math-extn-2010090
1/test/.build/test_extensions.ali -g -o /cygdrive/g/nabbasi/data/ada
_related/gnat-math-extn-20100901/test/test_extensions.exe
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgnalasup
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc.exe
gnatmake: *** link failed.
Is it possible to build this on cygwin as well in some future time? I
use cygwin mainly on windows and use gnat there, not on windows.
thanks again for this package, I will test it more.
--Nasser
Brian Drummond
>I just downloaded this and tried it. And this is a FYI:
>
>When I tried it under cygwin,
>using:
>
>$ gnatmake --version
>GNATMAKE 4.3.4 20090804 (release) 1
>Copyright (C) 1995-2007, Free Software Foundation, Inc.
>I get warning that libraries not supported:
>/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lgnalasup
Congratulations. You have just looped this thread...
Try the suggestions posted about a month ago under the same thread title.
- Brian
Simon Wright
(CYGWIN_NT-5.0 fenrirw 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin)
with no difficulty.
One obvious difference is that -- for you -- gnatmake reports its actions
with Unix-style names (/cygdrive/g/nabbasi/...) wherease I see
Windows-style file paths. However ...
I see no reference to libgnalasup.* (even when building with -bargs
-shared).
Time to upgrade, I think?