* ada lapack @ 2012-08-15 6:16 Leo Brewin 2012-08-16 3:34 ` Jerry 2012-08-17 6:25 ` Ada novice 0 siblings, 2 replies; 41+ messages in thread From: Leo Brewin @ 2012-08-15 6:16 UTC (permalink / raw) Greetings, I've made available a small set of Ada routines that implement a subset of the Lapack routines. These were created using Oliver Kellogg's f2a.pl script (many thanks) to port the Fortran code to Ada (followed by a lot of tweaks by hand). The code requires gnat2012. You can find the code on sourceforge at http://sourceforge.net/projects/ada-lapack/ Comments, opinions, suggestions etc. are most welcome. Cheers, Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-15 6:16 ada lapack Leo Brewin @ 2012-08-16 3:34 ` Jerry 2012-08-17 6:25 ` Ada novice 1 sibling, 0 replies; 41+ messages in thread From: Jerry @ 2012-08-16 3:34 UTC (permalink / raw) On Aug 14, 11:16 pm, Leo Brewin <leo.bre...@internode.on.net> wrote: > Greetings, > > I've made available a small set of Ada routines that implement a subset of the Lapack routines. These were created using Oliver Kellogg's f2a.pl script (many thanks) to port the Fortran code to Ada (followed by a lot of tweaks by hand). The code requires gnat2012. > > You can find the code on sourceforge at > > http://sourceforge.net/projects/ada-lapack/ > > Comments, opinions, suggestions etc. are most welcome. > > Cheers, > Leo Thanks for this work, Leo. I'll have a look. Jerry ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-15 6:16 ada lapack Leo Brewin 2012-08-16 3:34 ` Jerry @ 2012-08-17 6:25 ` Ada novice 2012-08-17 7:11 ` Leo Brewin 1 sibling, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-17 6:25 UTC (permalink / raw) On Wednesday, August 15, 2012 7:16:48 AM UTC+1, Leo Brewin wrote: > Greetings, > > I've made available a small set of Ada routines that implement a subset of the Lapack routines. > Comments, opinions, suggestions etc. are most welcome. > Thanks for this VERY important and useful contribution. I got some error messages when running "make tests". The only change that I made in the Makefile was to put my path for gnatmake as: /usr/local/gnat-2012/bin/gnatmake I am putting below the outputs that I get with "make" and "make tests". I do get all solutions as expected though. Errors that I am getting with "make tests" are as /bin/sh: 3: example01: not found and this for each test file. Here are my complete outputs: (a) make $ make for file in ada_lapack ada_lapack-extras example01 example02 example03 example04 tdgeev tdgesv tdgetri tzgeev tzgesv tzgetri; do make ${file}; done; make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 ada_lapack gcc -c -O3 -gnatwA -gnat2012 ada_lapack.adb ada_lapack.adb:9606:10: info: code between label and backwards goto rewritten as loop ada_lapack.adb:9632:10: info: code between label and backwards goto rewritten as loop ada_lapack.adb:31332:10: info: code between label and backwards goto rewritten as loop ada_lapack.adb:31358:10: info: code between label and backwards goto rewritten as loop make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 ada_lapack-extras gcc -c -O3 -gnatwA -gnat2012 ada_lapack-extras.adb make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 example01 gcc -c -O3 -gnatwA -gnat2012 example01.adb gnatbind -x example01.ali gnatlink example01.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 example02 gcc -c -O3 -gnatwA -gnat2012 example02.adb gnatbind -x example02.ali gnatlink example02.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 example03 gcc -c -O3 -gnatwA -gnat2012 example03.adb gnatbind -x example03.ali gnatlink example03.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 example04 gcc -c -O3 -gnatwA -gnat2012 example04.adb gnatbind -x example04.ali gnatlink example04.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tdgeev gcc -c -O3 -gnatwA -gnat2012 tdgeev.adb gnatbind -x tdgeev.ali gnatlink tdgeev.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tdgesv gcc -c -O3 -gnatwA -gnat2012 tdgesv.adb gnatbind -x tdgesv.ali gnatlink tdgesv.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tdgetri gcc -c -O3 -gnatwA -gnat2012 tdgetri.adb gnatbind -x tdgetri.ali gnatlink tdgetri.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tzgeev gcc -c -O3 -gnatwA -gnat2012 tzgeev.adb gnatbind -x tzgeev.ali gnatlink tzgeev.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tzgesv gcc -c -O3 -gnatwA -gnat2012 tzgesv.adb gnatbind -x tzgesv.ali gnatlink tzgesv.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' make[1]: Entering directory `/home/mint/work/ada/lapackport/ada_lapack' /usr/local/gnat-2012/bin/gnatmake -O3 -gnatwA -gnat2012 tzgetri gcc -c -O3 -gnatwA -gnat2012 tzgetri.adb gnatbind -x tzgetri.ali gnatlink tzgetri.ali -O3 make[1]: Leaving directory `/home/mint/work/ada/lapackport/ada_lapack' (b) make tests $ make tests Testing example01 /bin/sh: 3: example01: not found 0a1,2 > The eigenvaluess > ( -9.4299,-12.9833) ( -3.4418, 12.6897) ( 0.1055, -3.3950) ( 5.7562, 7.1286) Testing example02 /bin/sh: 3: example02: not found 0a1,8 > The eigenvalues > ( -9.4299,-12.9833) ( -3.4418, 12.6897) ( 0.1055, -3.3950) ( 5.7562, 7.1286) > > The right eigenvectors > ( 0.4309, 0.3268) ( 0.8257, 0.0000) ( 0.5984, 0.0000) ( -0.3054, 0.0333) > ( 0.5087, -0.0288) ( 0.0750, -0.2487) ( -0.4005, -0.2014) ( 0.0398, 0.3445) > ( 0.6198, 0.0000) ( -0.2458, 0.2789) ( -0.0901, -0.4753) ( 0.3583, 0.0606) > ( -0.2269, 0.1104) ( -0.1034, -0.3192) ( -0.4348, 0.1337) ( 0.8082, 0.0000) Testing example03 /bin/sh: 3: example03: not found 0a1,5 > Solution > ( -1.088, -0.183) ( 1.282, 1.205) > ( 0.966, 0.521) ( -0.222, -0.968) > ( -0.202, 0.187) ( 0.534, 1.358) > ( -0.586, 0.918) ( 2.222, -0.998) Testing example04 /bin/sh: 3: example04: not found 0a1,5 > Inverse > ( -0.113, -0.054) ( -0.086, 0.011) ( 0.127, 0.189) ( 0.155, -0.034) > ( 0.057, 0.057) ( 0.006, 0.013) ( -0.027, -0.098) ( -0.041, -0.034) > ( -0.059, -0.028) ( -0.093, 0.025) ( 0.042, 0.036) ( 0.014, 0.012) > ( -0.102, 0.067) ( 0.021, 0.126) ( 0.126, -0.095) ( 0.039, -0.114) Testing tdgeev /bin/sh: 3: tdgeev: not found 0a1,16 > The eigenvalues > ( 2.858, 10.763) ( 2.858,-10.763) ( -0.687, 4.704) ( -0.687, -4.704) -10.463 > > The left eigenvectors > ( 0.044, 0.288) ( 0.044, -0.288) ( -0.133, -0.327) ( -0.133, 0.327) 0.041 > ( 0.618, 0.000) ( 0.618, -0.000) ( 0.687, 0.000) ( 0.687, -0.000) 0.560 > ( -0.036, -0.577) ( -0.036, 0.577) ( -0.390, -0.075) ( -0.390, 0.075) -0.129 > ( 0.284, 0.011) ( 0.284, -0.011) ( -0.018, -0.187) ( -0.018, 0.187) -0.797 > ( -0.045, 0.341) ( -0.045, -0.341) ( -0.403, 0.218) ( -0.403, -0.218) 0.183 > > The right eigenvectors > ( 0.108, 0.169) ( 0.108, -0.169) ( 0.732, 0.000) ( 0.732, -0.000) 0.461 > ( 0.406, -0.259) ( 0.406, 0.259) ( -0.026, -0.017) ( -0.026, 0.017) 0.338 > ( 0.102, -0.509) ( 0.102, 0.509) ( 0.192, -0.293) ( 0.192, 0.293) 0.309 > ( 0.399, -0.091) ( 0.399, 0.091) ( -0.079, -0.078) ( -0.079, 0.078) -0.744 > ( 0.540, 0.000) ( 0.540, -0.000) ( -0.292, -0.493) ( -0.292, 0.493) 0.159 Testing tdgesv /bin/sh: 3: tdgesv: not found 0a1,32 > Solution > 4.020 -1.560 9.810 > 6.190 4.000 -4.090 > -8.220 -8.670 -4.570 > -7.570 1.750 -8.610 > -3.030 2.860 8.990 > > The LU factorization > 8.230 1.080 9.040 2.140 -6.870 > 0.826 -6.942 -7.919 6.552 -3.994 > 0.688 -0.665 -14.184 7.236 -5.191 > 0.725 0.752 0.023 -13.820 14.189 > -0.256 0.435 -0.588 -0.337 -3.429 > > The pivot indices > ( 5 5 3 4 5 ) > > The original matrix > 6.800 -6.050 -0.450 8.320 -9.670 > -2.110 -3.300 2.580 2.710 -5.140 > 5.660 5.360 -2.700 4.350 -7.260 > 5.970 -4.440 0.270 -7.170 6.080 > 8.230 1.080 9.040 2.140 -6.870 > > The reconstructed matrix > 6.800 -6.050 -0.450 8.320 -9.670 > -2.110 -3.300 2.580 2.710 -5.140 > 5.660 5.360 -2.700 4.350 -7.260 > 5.970 -4.440 0.270 -7.170 6.080 > 8.230 1.080 9.040 2.140 -6.870 > > The residual error : 2.1413E-18 Testing tdgetri /bin/sh: 3: tdgetri: not found 0a1,15 > The optimal value for LWORK is 320 > > Matrix > 6.800 -6.050 -0.450 8.320 -9.670 > -2.110 -3.300 2.580 2.710 -5.140 > 5.660 5.360 -2.700 4.350 -7.260 > 5.970 -4.440 0.270 -7.170 6.080 > 8.230 1.080 9.040 2.140 -6.870 > > Inverse > 0.048 -0.107 0.003 0.027 0.033 > -0.052 -0.062 0.045 -0.047 0.030 > -0.005 -0.046 -0.096 -0.052 0.096 > 0.146 -0.299 -0.172 -0.173 0.046 > 0.088 -0.292 -0.169 -0.098 0.040 Testing tzgeev /bin/sh: 3: tzgeev: not found 0a1,16 > The optimal value for LWORK is 132 > > The eigenvalues > ( -9.4299,-12.9833) ( -3.4418, 12.6897) ( 0.1055, -3.3950) ( 5.7562, 7.1286) > > The left eigenvectors > ( 0.2414, -0.1847) ( 0.6135, 0.0000) ( -0.1828, -0.3347) ( 0.2765, 0.0884) > ( 0.7861, 0.0000) ( -0.0499, -0.2721) ( 0.8218, 0.0000) ( -0.5477, 0.1572) > ( 0.2195, -0.2689) ( -0.2088, 0.5347) ( -0.3714, 0.1525) ( 0.4451, 0.0912) > ( -0.0170, 0.4109) ( 0.4027, -0.2353) ( 0.0575, 0.1208) ( 0.6202, 0.0000) > > The right eigenvectors > ( 0.4309, 0.3268) ( 0.8257, 0.0000) ( 0.5984, 0.0000) ( -0.3054, 0.0333) > ( 0.5087, -0.0288) ( 0.0750, -0.2487) ( -0.4005, -0.2014) ( 0.0398, 0.3445) > ( 0.6198, 0.0000) ( -0.2458, 0.2789) ( -0.0901, -0.4753) ( 0.3583, 0.0606) > ( -0.2269, 0.1104) ( -0.1034, -0.3192) ( -0.4348, 0.1337) ( 0.8082, 0.0000) Testing tzgesv /bin/sh: 3: tzgesv: not found 0a1,28 > Solution > ( 8.330, -7.320) ( -6.110, -3.810) > ( -6.180, -4.800) ( 0.140, -7.710) > ( -5.710, -2.800) ( 1.410, 3.400) > ( -1.600, 3.080) ( 8.540, -4.050) > > The LU factorization > ( -4.300, -7.100) ( -6.470, 2.520) ( -6.510, -2.670) ( -5.860, 7.380) > ( 0.490, 0.470) ( 12.265, -3.574) ( -7.865, -0.492) ( -0.980, 6.708) > ( 0.249, -0.151) ( -0.601, -0.370) (-11.699, -4.642) ( -1.353, 1.376) > ( -0.830, -0.324) ( 0.052, 0.579) ( 0.933, -0.499) ( 2.664, 7.857) > > The pivot indices > ( 3 3 3 4 ) > > The original matrix > ( 1.230, -5.500) ( 7.910, -5.380) ( -9.800, -4.860) ( -7.320, 7.570) > ( -2.140, -1.120) ( -9.920, -0.790) ( -9.180, -1.120) ( 1.370, 0.430) > ( -4.300, -7.100) ( -6.470, 2.520) ( -6.510, -2.670) ( -5.860, 7.380) > ( 1.270, 7.290) ( 8.900, 6.920) ( -8.820, 1.250) ( 5.410, 5.370) > > The reconstructed matrix > ( 1.230, -5.500) ( 7.910, -5.380) ( -9.800, -4.860) ( -7.320, 7.570) > ( -2.140, -1.120) ( -9.920, -0.790) ( -9.180, -1.120) ( 1.370, 0.430) > ( -4.300, -7.100) ( -6.470, 2.520) ( -6.510, -2.670) ( -5.860, 7.380) > ( 1.270, 7.290) ( 8.900, 6.920) ( -8.820, 1.250) ( 5.410, 5.370) > > The residual error : 3.9701E-18 Testing tzgetri /bin/sh: 3: tzgetri: not found 0a1,13 > The optimal value for LWORK is 256 > > Matrix > ( 1.230, -5.500) ( 7.910, -5.380) ( -9.800, -4.860) ( -7.320, 7.570) > ( -2.140, -1.120) ( -9.920, -0.790) ( -9.180, -1.120) ( 1.370, 0.430) > ( -4.300, -7.100) ( -6.470, 2.520) ( -6.510, -2.670) ( -5.860, 7.380) > ( 1.270, 7.290) ( 8.900, 6.920) ( -8.820, 1.250) ( 5.410, 5.370) > > Inverse > ( -0.113, -0.054) ( -0.086, 0.011) ( 0.127, 0.189) ( 0.155, -0.034) > ( 0.057, 0.057) ( 0.006, 0.013) ( -0.027, -0.098) ( -0.041, -0.034) > ( -0.059, -0.028) ( -0.093, 0.025) ( 0.042, 0.036) ( 0.014, 0.012) > ( -0.102, 0.067) ( 0.021, 0.126) ( 0.126, -0.095) ( 0.039, -0.114) make: *** [tests] Error 1 $ Do I need to fix something? Thanks. YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 6:25 ` Ada novice @ 2012-08-17 7:11 ` Leo Brewin 2012-08-17 7:42 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Leo Brewin @ 2012-08-17 7:11 UTC (permalink / raw) Hmm, that's odd. I can only guess that your binaries, example01, etc. are not where "make tests" is expecting to find them. Try typing cd ada_lapack; ls ex*; ls t* If you don't see the binaries then that would explain the errors you saw (the output you saw was from a diff command, it wasn't from your binaries). You may have to hunt around for them (and I don't know why they would be anywhere other than in ada_lapack). Cheers, Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 7:11 ` Leo Brewin @ 2012-08-17 7:42 ` Ada novice 2012-08-17 9:43 ` Niklas Holsti 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-17 7:42 UTC (permalink / raw) On Friday, August 17, 2012 8:11:33 AM UTC+1, Leo Brewin wrote: > > If you don't see the binaries then that would explain the errors you saw (the output you saw was from a diff command, it wasn't from your binaries). > Here is the output: I@you ~/work/ada/lapackport/ada_lapack $ ls ex*; ls t* example01 example01.txt example02.o example03.ali example04.adb example01.adb example02 example02.txt example03.o example04.ali example01.ali example02.adb example03 example03.txt example04.o example01.o example02.ali example03.adb example04 example04.txt tdgeev tdgesv tdgetri tzgeev tzgesv tzgetri tdgeev.adb tdgesv.adb tdgetri.adb tzgeev.adb tzgesv.adb tzgetri.adb tdgeev.ali tdgesv.ali tdgetri.ali tzgeev.ali tzgesv.ali tzgetri.ali tdgeev.o tdgesv.o tdgetri.o tzgeev.o tzgesv.o tzgetri.o tdgeev.txt tdgesv.txt tdgetri.txt tzgeev.txt tzgesv.txt tzgetri.txt I@you ~/work/ada/lapackport/ada_lapack $ What do you mean by binaries? Are the above files binaries? Thanks YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 7:42 ` Ada novice @ 2012-08-17 9:43 ` Niklas Holsti 2012-08-17 10:27 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-08-17 9:43 UTC (permalink / raw) On 12-08-17 10:42 , Ada novice wrote: > On Friday, August 17, 2012 8:11:33 AM UTC+1, Leo Brewin wrote: >> >> If you don't see the binaries then that would explain the errors you saw (the output you saw was from a diff command, it wasn't from your binaries). >> > > Here is the output: > > I@you ~/work/ada/lapackport/ada_lapack $ ls ex*; ls t* > example01 example01.txt example02.o example03.ali example04.adb > example01.adb example02 example02.txt example03.o example04.ali > example01.ali example02.adb example03 example03.txt example04.o > example01.o example02.ali example03.adb example04 example04.txt > tdgeev tdgesv tdgetri tzgeev tzgesv tzgetri > tdgeev.adb tdgesv.adb tdgetri.adb tzgeev.adb tzgesv.adb tzgetri.adb > tdgeev.ali tdgesv.ali tdgetri.ali tzgeev.ali tzgesv.ali tzgetri.ali > tdgeev.o tdgesv.o tdgetri.o tzgeev.o tzgesv.o tzgetri.o > tdgeev.txt tdgesv.txt tdgetri.txt tzgeev.txt tzgesv.txt tzgetri.txt > I@you ~/work/ada/lapackport/ada_lapack $ > > What do you mean by binaries? Are the above files binaries? The files without a suffix, such as example01, are most likely the binaries, also called executables. > Thanks > YC The problem is probably that the "tests" target in the Makefile incorrectly assumes that your PATH contains ".", the current working directory. The relevant line is: $${file} > $${file}.txt; \ Change this line to have a ./ at the start: ./$${file} > $${file}.txt; \ and it should work. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 9:43 ` Niklas Holsti @ 2012-08-17 10:27 ` Ada novice 2012-08-17 11:08 ` Niklas Holsti 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-17 10:27 UTC (permalink / raw) On Friday, August 17, 2012 10:43:22 AM UTC+1, Niklas Holsti wrote: > Change this line to have a ./ at the start: > > > > ./$${file} > $${file}.txt; \ > Thanks. It works! I did the operations from scratch from the .tgz file. And now, $ make tests Testing example01 Testing example02 Testing example03 Testing example04 Testing tdgeev Testing tdgesv Testing tdgetri Testing tzgeev Testing tzgesv Testing tzgetri and for instance, $ ./tzgetri The optimal value for LWORK is 256 Matrix ( 1.230, -5.500) ( 7.910, -5.380) ( -9.800, -4.860) ( -7.320, 7.570) ( -2.140, -1.120) ( -9.920, -0.790) ( -9.180, -1.120) ( 1.370, 0.430) ( -4.300, -7.100) ( -6.470, 2.520) ( -6.510, -2.670) ( -5.860, 7.380) ( 1.270, 7.290) ( 8.900, 6.920) ( -8.820, 1.250) ( 5.410, 5.370) Inverse ( -0.113, -0.054) ( -0.086, 0.011) ( 0.127, 0.189) ( 0.155, -0.034) ( 0.057, 0.057) ( 0.006, 0.013) ( -0.027, -0.098) ( -0.041, -0.034) ( -0.059, -0.028) ( -0.093, 0.025) ( 0.042, 0.036) ( 0.014, 0.012) ( -0.102, 0.067) ( 0.021, 0.126) ( 0.126, -0.095) ( 0.039, -0.114) I am curious to know why "make tests" in my earlier case was giving me the outputs of the matrices while now with the new Makefile, I get only Testing example01 Testing example02 Testing example03 Testing example04 Testing tdgeev Testing tdgesv Testing tdgetri Testing tzgeev Testing tzgesv Testing tzgetri and without the matrix outputs? > The files without a suffix, such as example01, are most likely the > binaries, also called executables. Ok. On my linux system, these files are also in a different colour from the rest. Best regards, YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 10:27 ` Ada novice @ 2012-08-17 11:08 ` Niklas Holsti 2012-08-17 11:33 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-08-17 11:08 UTC (permalink / raw) On 12-08-17 13:27 , Ada novice wrote: > On Friday, August 17, 2012 10:43:22 AM UTC+1, Niklas Holsti wrote: > >> Change this line to have a ./ at the start: >> >> >> >> ./$${file} > $${file}.txt; \ >> > > Thanks. It works! Good. > I am curious to know why "make tests" in my earlier > case was giving me the outputs of the matrices while > now with the new Makefile, I get only > > Testing example01 > Testing example02 ... Because the Makefile applies "diff" to compare the actual output from running e.g. the example01 executable and a reference file in the "output" subfolder. If the files match, "diff" prints nothing. This is the "no news is good news" principle -- a sucessful test is silent. In your first try, the shell did not find the executable, so the actual output file (./example01.txt) became empty, and "diff" showed all the lines in the reference file (output/example01.txt) as "difference" lines. >> The files without a suffix, such as example01, are most likely the >> binaries, also called executables. > > Ok. On my linux system, these files are also in a different colour from the rest. That depends on the options you use with the "ls" command. (I always turn off the "color" option -G and use the suffix-flagging option -F instead, because I find it more readable.) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 11:08 ` Niklas Holsti @ 2012-08-17 11:33 ` Ada novice 2012-08-17 13:45 ` Leo Brewin 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-17 11:33 UTC (permalink / raw) On Friday, August 17, 2012 12:08:38 PM UTC+1, Niklas Holsti wrote: > In your first try, the shell did not find the executable, so the actual > > output file (./example01.txt) became empty, and "diff" showed all the > > lines in the reference file (output/example01.txt) as "difference" lines. Thanks. Yes we have the diff command just afterwards in the Makefile. YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 11:33 ` Ada novice @ 2012-08-17 13:45 ` Leo Brewin 2012-08-17 14:11 ` Marc C 2012-08-17 14:12 ` Brian Drummond 0 siblings, 2 replies; 41+ messages in thread From: Leo Brewin @ 2012-08-17 13:45 UTC (permalink / raw) I've just returned from watching my football team lose (again), that was the bad news. The good news is that Niklas did my job for me -- solving the problems with the errant Makefile. Thanks Niklas. I had assumed that everybody would have . in their path. Is this a reasonable assumption? But just to be on the safe side I'll update the Makefile. Cheers, Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 13:45 ` Leo Brewin @ 2012-08-17 14:11 ` Marc C 2012-08-18 11:57 ` Ada novice 2012-08-17 14:12 ` Brian Drummond 1 sibling, 1 reply; 41+ messages in thread From: Marc C @ 2012-08-17 14:11 UTC (permalink / raw) On Friday, August 17, 2012 8:45:42 AM UTC-5, Leo Brewin wrote: > I had assumed that everybody would have . in their path. Is this a reasonable assumption? No, it's not. All the recent Linux distributions I've used, at home and at work, do not out-of-the-box include the current directory on the default PATH. Marc A. Criley ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 14:11 ` Marc C @ 2012-08-18 11:57 ` Ada novice 2012-08-18 13:13 ` Niklas Holsti 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-18 11:57 UTC (permalink / raw) If in an example file given say example01.adb one needs to add 2 matrices. We have the given "matrix" and we can make a copy "matrix_copy". Writing sum_two_matrices := matrix + matrix_copy; gives an compilation error ---there is no applicable operator "+" for type "Complex_Matrix" at ada_lapack.ads:69, instance at line 24--- The Complex_Matrix type defined in G.3.2 complex vectors and matrices of the ARM can do addition + operations. The Complex_Matrix as defined in ada_lapack.ads:69 seems different. Thanks YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 11:57 ` Ada novice @ 2012-08-18 13:13 ` Niklas Holsti 2012-08-18 13:48 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-08-18 13:13 UTC (permalink / raw) On 12-08-18 14:57 , Ada novice wrote: > If in an example file given say example01.adb one needs to add 2 > matrices. We have the given "matrix" and we can make a copy > "matrix_copy". Writing > > sum_two_matrices := matrix + matrix_copy; > > gives an compilation error > > ---there is no applicable operator "+" for type "Complex_Matrix" at > ada_lapack.ads:69, instance at line 24--- > > The Complex_Matrix type defined in G.3.2 complex vectors and matrices > of the ARM can do addition + operations. The Complex_Matrix as > defined in ada_lapack.ads:69 seems different. They are indeed different types. The standard package Ada.Numerics.Generic_Complex_Arrays provides the "+" operator (and several other operators) but ada_lapack.ads does not. If you want a "+" for Ada_Lapack.Complex_Matrix, you must define one yourself, either in ada_lapack.ads/adb (best option) or in your own code. You code the "+" function just like any other Ada function, except that its name is "+": function "+" (Left, Right : Complex_Matrix) return Complex_Matrix is begin ... end "+"; -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 13:13 ` Niklas Holsti @ 2012-08-18 13:48 ` Ada novice 2012-08-18 15:22 ` Nasser M. Abbasi 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-18 13:48 UTC (permalink / raw) Thanks. This is rather unfortunate to see that one cannot use the many operators and functions in Ada.Numerics.Generic_Complex_Arrays in example file example01.adb automatically. Adding two matrices is simple but other functions are not so easy to implement. YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 13:48 ` Ada novice @ 2012-08-18 15:22 ` Nasser M. Abbasi 2012-08-18 16:33 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-18 15:22 UTC (permalink / raw) On 8/18/2012 8:48 AM, Ada novice wrote: > Thanks. This is rather unfortunate to see that one cannot use the many operators >and functions in Ada.Numerics.Generic_Complex_Arrays in example file example01.adb >automatically. Adding two matrices is simple but other functions are not so easy to implement. > > YC > I already found this "issue" and mentioned it before here in this newsgroup when I was working on the Ada Lapack package by Wasu Chaopanon. see http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-07/msg00290.html "The Ada lapack binding defines its own Matrix types. However, it does not define operators (multiply, add, etc.. ) to work on these types similar to Ada's Real Vectors and Matrices in the Ada.Numerics.Real_Arrays package" Yes. Each time a new type is made, one in Ada, you must define a new set of operators on this type. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 15:22 ` Nasser M. Abbasi @ 2012-08-18 16:33 ` Ada novice 2012-08-18 17:32 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Ada novice @ 2012-08-18 16:33 UTC (permalink / raw) Yes Nasser I do remember that post of yours well. That's a pity. I hope that someone can come up with a solution to this problem. It's unblievable that one has to "reinvent the wheel". Of course in the same program, one would want to be able to mix the lapack codes with those of Ada numerics seamlessly. It's definitely an issue that Ada programmers need to look into if we would like to attract people to use Ada. YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 16:33 ` Ada novice @ 2012-08-18 17:32 ` Simon Wright 2012-08-18 17:44 ` Nasser M. Abbasi 2012-08-18 20:45 ` Niklas Holsti 2012-08-19 2:20 ` Leo Brewin 2 siblings, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-08-18 17:32 UTC (permalink / raw) Ada novice <shai.lesh@gmx.com> writes: > I hope that someone can come up with a solution to this problem. It's > unblievable that one has to "reinvent the wheel". Of course in the > same program, one would want to be able to mix the lapack codes with > those of Ada numerics seamlessly. The types from Ada.Numerics are convention Ada by default, while the types in Ada_Lapack are convention Fortran. It would be nice to be able to say something like with Ada.Numerics.Generic_Complex_Arrays; generic with package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays (<>); package Conventions is type Complex_Matrix is new Complex_Arrays.Complex_Matrix with Convention => Fortran; which would give you the operations you want, but unfortunately gcc -c -gnat12 conventions.ads conventions.ads:9:46: representation item appears too late conventions.ads:9:46: primitive operations already defined for "Complex_Matrix" gnatmake: "conventions.ads" compilation error > It's definitely an issue that Ada programmers need to look into if we > would like to attract people to use Ada. Who are these "Ada programmers"? Looks to me as though it's you, Leo and Nasser! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 17:32 ` Simon Wright @ 2012-08-18 17:44 ` Nasser M. Abbasi 0 siblings, 0 replies; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-18 17:44 UTC (permalink / raw) On 8/18/2012 12:32 PM, Simon Wright wrote: > Who are these "Ada programmers"? Looks to me as though it's you, Leo and > Nasser! > We are the three musketeers ? ;) I agree with you that more programmers asking for using Ada for numerical and scientific work is needed before Ada experts like you and others and and those in Ada core will even pay any attention to the noise we are making. Ofcourse, if someone comes with 10 million dollars to sponsor a software project to make Ada the best for numerical and computational work, then things might be different. We need someone like Bill Gates to become interested in using Ada for numerical work for this to happen I guess. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 16:33 ` Ada novice 2012-08-18 17:32 ` Simon Wright @ 2012-08-18 20:45 ` Niklas Holsti 2012-08-18 21:46 ` Simon Wright 2012-08-18 22:51 ` Nasser M. Abbasi 2012-08-19 2:20 ` Leo Brewin 2 siblings, 2 replies; 41+ messages in thread From: Niklas Holsti @ 2012-08-18 20:45 UTC (permalink / raw) On 12-08-18 19:33 , Ada novice wrote: > Yes Nasser I do remember that post of yours well. That's a pity. > > I hope that someone can come up with a solution to this problem. It's > unblievable that one has to "reinvent the wheel". Of course in the > same program, one would want to be able to mix the lapack codes with > those of Ada numerics seamlessly. The problem is that Ada_Lapack is a conversion from Fortran to Fortran-style Ada, and not a true native Ada implementation. I wonder why Ada_Lapack needs convention-Fortran matrices, when it does not use any Fortran code. Perhaps the reason is the frequent use in Ada_Lapack of "for X'Address use Y", where X is an array. Yuck. But writing a native Ada clone of LAPACK could be a lot of work, and might need some deep understanding of how the Fortran LAPACK works. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 20:45 ` Niklas Holsti @ 2012-08-18 21:46 ` Simon Wright 2012-08-19 2:24 ` Leo Brewin 2012-08-18 22:51 ` Nasser M. Abbasi 1 sibling, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-08-18 21:46 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > I wonder why Ada_Lapack needs convention-Fortran matrices, when it > does not use any Fortran code. Perhaps the reason is the frequent use > in Ada_Lapack of "for X'Address use Y", where X is an array. Yuck. But > writing a native Ada clone of LAPACK could be a lot of work, and might > need some deep understanding of how the Fortran LAPACK works. Just for fun I tried replacing convention Fortran with convention Ada. *Not* a success :-( ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 21:46 ` Simon Wright @ 2012-08-19 2:24 ` Leo Brewin 2012-08-19 5:39 ` Ada novice 0 siblings, 1 reply; 41+ messages in thread From: Leo Brewin @ 2012-08-19 2:24 UTC (permalink / raw) Looking through the Fortran sources for Lapack reveals lines like CALL DSCAL( N, S, V( K, 1 ), LDV ) and CALL DSCAL( N, S, V( 1, K ), 1 ) In the first case the intention is to scale row K of the matrix V by S, in the second case column K of V is rescaled. This is implemented in DSCAL by recasting V as a long vector DX. Stepping over columns of V is then equivalent to stepping through (a subset of) DX using a constant stride (LDV for the first case, 1 for the second). This is one example where Lapack makes explicit use of Fortran column major convention. There may be other examples (not just with DSCAL, I haven't checked). So, taking the approach of minimalist intervention, I opted to declare the Ada array types with the Fortran convention. Is there a penalty with this? I doubt it. At worst it's the cost of taking a transpose, which need only be done outside the Lapack code and should not add significantly to the overall execution time (which will be dominated by the Lapack code). In other places you will see code like CALL DSCAL( N, S, X, INCX ) where X is a vector. Converting each of these examples into Ada poses a problem. If we declare DSCAL as procedure DSCAL (N : Integer; S : Real; DX : in out Real_Vector; INCX : Integer); then the calls DSCAL (N,S,V(K,1),LDV); DSCAL (N,S,V(1,K),1); will give a compile time error, while DSCAL (N,S,X,INCX); can succeed (assuming X is of type Real_Vector). Changing the specification for DSCAL could solve the problem for the first two cases but will cause the third case to fail. The only solution that I could come up with (there may be others) was to pass the third argument by Address. Unless someone (not me) is prepared to re-write the Lapack code in Ada, from scratch, we are stuck with these kludges. I don't really care what the Ada version of the Lapack code looks like, I never plan to rewrite any of the Lapack side of the Ada_Lapack code and I never intend to call any of the Lapack codes directly (I use the interface routines like MatrixInverse). So it's not an issue for me if the code contains some of these oddities. The bottom line is -- it works, and that is all I need. Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-19 2:24 ` Leo Brewin @ 2012-08-19 5:39 ` Ada novice 2012-08-19 7:10 ` Leo Brewin 0 siblings, 1 reply; 41+ messages in thread From: Ada novice @ 2012-08-19 5:39 UTC (permalink / raw) Think of Matlab. It uses lapack but I do not think that the lapack codes are written in the Matlab language. A higher function like "eig" in Matlab is calling the necessary lapack routine and this part is invisible to the user. But after calling "eig", the user can do whatever operation he/she wants on the eigenvectors. This is the reason why Matlab sells and we have free software like scilab and octave which can also do similar things. If after getting the eigenvalues from the above software one would not be able to apply other operations such as "adding" in my example without implementing an "add" function, then software like Matlab, Scilab and Octave would not be popular at all. What we need in Ada are people who have been using the scientific computation software mentioned above to think how to make Ada more accessible. Those who design the Numerics annex should really think WHY they are providing these mathematical functions and to what extent these are useful in practice. Perhaps none of Ada core customers is involved in heavy matrix computations. All this reminds me of the OS of one best sold smartphones; either you like what the developers are giving you or you don't. The developers do not care about user feedback. If Ada people continue to have this mentality, then Ada will only be for the niche market unlike that phone which sells well because of the feeling of prestige it gives! Leo and Nasser should be very much commended for their efforts to make lapack possible with Ada. And Simon also for his math extension package for eigensysyem computation. But a greater involvement from the Ada community is needed. As Nasser pointed out, perhaps we need our own Ada Bill Gates! YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-19 5:39 ` Ada novice @ 2012-08-19 7:10 ` Leo Brewin 2012-08-19 13:02 ` Simon Wright 0 siblings, 1 reply; 41+ messages in thread From: Leo Brewin @ 2012-08-19 7:10 UTC (permalink / raw) Here is your chance to make a contribution. You have the source code, make the changes for what you think it should be and post it back to the community. We'd appreciate your efforts. Seize the moment. Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-19 7:10 ` Leo Brewin @ 2012-08-19 13:02 ` Simon Wright 2012-08-20 14:05 ` Nasser M. Abbasi 0 siblings, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-08-19 13:02 UTC (permalink / raw) Leo Brewin <leo.brewin@internode.on.net> writes: > Here is your chance to make a contribution. You have the source code, > make the changes for what you think it should be and post it back to > the community. We'd appreciate your efforts. Seize the moment. I'm not promising _anything_, but personally I'd find it easier to do this if the source was on Sourceforge in some version control system. My vote would be, in descending order of preference, Mercurial (Hg) git and, trailing by a long way, Subversion (svn) (SF isn't supporting CVS any more for new projects, a Good Thing). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-19 13:02 ` Simon Wright @ 2012-08-20 14:05 ` Nasser M. Abbasi 2012-08-20 14:57 ` Simon Wright 2012-08-20 15:03 ` Nasser M. Abbasi 0 siblings, 2 replies; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-20 14:05 UTC (permalink / raw) On 8/19/2012 8:02 AM, Simon Wright wrote: > > I'm not promising _anything_, but personally I'd find it easier to do > this if the source was on Sourceforge in some version control system. My > vote would be, in descending order of preference, > > Mercurial (Hg) > git > > and, trailing by a long way, > > Subversion (svn) > > (SF isn't supporting CVS any more for new projects, a Good Thing). > Simon, yes ofcourse, Ada Lapack and Ada Blas bindings should be in source control somewhere so that any one can make changes and improvements to the same source. I can make a sourceForge project for it now and put the Lapack and Blas sources there, which are based on the original ones (BLAS Ada binding written by Duncan Sands and the LAPACK Ada binding written by Wasu Chaopanon). I will use the current snapshot I have here http://12000.org/my_notes/ada/lapack_and_blas/index.htm where I just added documentation and moved the packages into one package, and cleaned up the build makefiles and no code changes was done in the actual binding itself. I do not know how to use the source control you mention above (actually I do not know how to make a sourceForge project, but will find out. Before someone took my c2Ada updates and they put it in sourceForge for me.) If you prefer to do that, since you seem to know these things much better than me, please do so. If you are busy, I'll figure it out and put the above sources into sourceForge and make an Ada Lapack and Ada Blas projects there. and post a link to it here. This is a good idea, so that one knows where the code is and no need to go search the net for different places for it. thanks, --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 14:05 ` Nasser M. Abbasi @ 2012-08-20 14:57 ` Simon Wright 2012-08-20 15:10 ` Nasser M. Abbasi 2012-08-20 18:46 ` Nasser M. Abbasi 2012-08-20 15:03 ` Nasser M. Abbasi 1 sibling, 2 replies; 41+ messages in thread From: Simon Wright @ 2012-08-20 14:57 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > On 8/19/2012 8:02 AM, Simon Wright wrote: > >> >> I'm not promising _anything_, but personally I'd find it easier to do >> this if the source was on Sourceforge in some version control system. My >> vote would be, in descending order of preference, >> >> Mercurial (Hg) >> git >> >> and, trailing by a long way, >> >> Subversion (svn) >> >> (SF isn't supporting CVS any more for new projects, a Good Thing). >> > > Simon, yes ofcourse, Ada Lapack and Ada Blas bindings should be > in source control somewhere so that any one can make changes and > improvements to the same source. What I meant was that the SF project that Leo has already set up for Ada_Lapack would be even better if it had the source code in source control, rather than just as an archive. If I was enrolled as a developer on the project I could do that, if Leo wanted. SF username simonjwright. > I can make a sourceForge project for it now and put the Lapack > and Blas sources there, which are based on the original ones > (BLAS Ada binding written by Duncan Sands and the LAPACK Ada > binding written by Wasu Chaopanon). > > I will use the current snapshot I have here > > http://12000.org/my_notes/ada/lapack_and_blas/index.htm > > where I just added documentation and moved the packages into > one package, and cleaned up the build makefiles and no code changes > was done in the actual binding itself. > > I do not know how to use the source control you mention above > (actually I do not know how to make a sourceForge project, but > will find out. Before someone took my c2Ada updates and they > put it in sourceForge for me.) > > If you prefer to do that, since you seem to know these things > much better than me, please do so. If you are busy, I'll figure > it out and put the above sources into sourceForge and make > an Ada Lapack and Ada Blas projects there. and post a link > to it here. I think I agree with you that your work ought to be in a different SF project. Or projects, whichever you think best (though I'd go for one). I'd be quite happy to organise this. Perhaps we should take any further organisational details to e-mail and come back to the group when done? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 14:57 ` Simon Wright @ 2012-08-20 15:10 ` Nasser M. Abbasi 2012-08-20 18:09 ` Ada novice 2012-08-20 18:46 ` Nasser M. Abbasi 1 sibling, 1 reply; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-20 15:10 UTC (permalink / raw) On 8/20/2012 9:57 AM, Simon Wright wrote: > > What I meant was that the SF project that Leo has already set up for > Ada_Lapack would be even better if it had the source code in source > control, rather than just as an archive. If I was enrolled as a > developer on the project I could do that, if Leo wanted. SF username > simonjwright. > Simon, I added your account to these 2 projects as admin now https://sourceforge.net/p/adablas/wiki/Home/ https://sourceforge.net/p/adalapack/wiki/Home/ The sources I have above have been modified to make Ada Lapack ONE package. These were based on the original Ada Lacack work by Wasu Chaopanon. I am not familiar with what Leo has there. Better to have one ada lapack and not few different versions. >> >> I will use the current snapshot I have here >> >> http://12000.org/my_notes/ada/lapack_and_blas/index.htm >> regards, --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 15:10 ` Nasser M. Abbasi @ 2012-08-20 18:09 ` Ada novice 0 siblings, 0 replies; 41+ messages in thread From: Ada novice @ 2012-08-20 18:09 UTC (permalink / raw) Good luck guys in this ambitious adventure. I can only be involved in the testing afterwards as I still have basic Ada programming skills. I will keep track of your posts here. I may come up with suggestions after you have some working codes so as to narrow the gap between Ada and a numerical computaton software like Matlab if needed. YC ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 14:57 ` Simon Wright 2012-08-20 15:10 ` Nasser M. Abbasi @ 2012-08-20 18:46 ` Nasser M. Abbasi 1 sibling, 0 replies; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-20 18:46 UTC (permalink / raw) On 8/20/2012 9:57 AM, Simon Wright wrote: > > What I meant was that the SF project that Leo has already set up for > Ada_Lapack would be even better if it had the source code in source > control, rather than just as an archive. If I was enrolled as a > developer on the project I could do that, if Leo wanted. I just wanted to say that is not important which project at SF the code goes or even which snap shot is used, as long as there is one set of code base. I think the changes I made to make the binding one package instead of 4 makes it easier to use Lapack but these are not critical changes to the API itself. I used the original Ada Blas and Lapack code. Did not write anything myself. It will be better for Ada if Lapack and Blas code was in source control and everyone knows which source to use. That is the important thing. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 14:05 ` Nasser M. Abbasi 2012-08-20 14:57 ` Simon Wright @ 2012-08-20 15:03 ` Nasser M. Abbasi 2012-08-20 22:57 ` Simon Wright 2012-08-21 10:44 ` Simon Wright 1 sibling, 2 replies; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-20 15:03 UTC (permalink / raw) On 8/20/2012 9:05 AM, Nasser M. Abbasi wrote: > > I can make a sourceForge project for it now and put the Lapack > and Blas sources there, which are based on the original ones > (BLAS Ada binding written by Duncan Sands and the LAPACK Ada > binding written by Wasu Chaopanon). > I've created an adablas and adalapack projects at source forge https://sourceforge.net/p/adablas/wiki/Home/ https://sourceforge.net/p/adalapack/wiki/Home/ I am just not sure how to use git to upload what I have here http://12000.org/my_notes/ada/lapack_and_blas/index.htm to the above. I never used git before. Need more time to figure it out. If someone knows already how to use git and sourceforge and would like to do this (just to upload the 2 zip files I have in my web page above (at the bottom of the page) to the above projects, that is all. Just let me know, and will add you as an admin to these projects so you can update them. Just need your sourceForge account name to add you as an admin so you can do that. You will become another admin to these projects from now on. ..back to learning git .... thanks, --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 15:03 ` Nasser M. Abbasi @ 2012-08-20 22:57 ` Simon Wright 2012-08-20 23:09 ` Nasser M. Abbasi 2012-08-21 10:44 ` Simon Wright 1 sibling, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-08-20 22:57 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > On 8/20/2012 9:05 AM, Nasser M. Abbasi wrote: > >> >> I can make a sourceForge project for it now and put the Lapack and >> Blas sources there, which are based on the original ones (BLAS Ada >> binding written by Duncan Sands and the LAPACK Ada binding written by >> Wasu Chaopanon). >> > > I've created an adablas and adalapack projects at source forge > > https://sourceforge.net/p/adablas/wiki/Home/ > https://sourceforge.net/p/adalapack/wiki/Home/ > > I am just not sure how to use git to upload what I have > here > > http://12000.org/my_notes/ada/lapack_and_blas/index.htm > > to the above. I never used git before. Need more time to > figure it out. > > If someone knows already how to use git and sourceforge and would like > to do this (just to upload the 2 zip files I have in my web page above > (at the bottom of the page) to the above projects, that is all. I've updated the adablas project (leaving out the test/ executables that had made their way into the zip file!) but am unsure about the adalapack project; there are quite a lot of files named, or in directories named, OLD. Also, I don't think the convert/ directory is useful any more? Please advise. I can see that people using GPS would want to use git (or svn, or even cvs) because GPS supports them, and doesn't support hg. But I still think that git is far more complex than most people need. We are not Linus Torvalds! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 22:57 ` Simon Wright @ 2012-08-20 23:09 ` Nasser M. Abbasi 2012-08-20 23:31 ` Simon Wright 0 siblings, 1 reply; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-20 23:09 UTC (permalink / raw) On 8/20/2012 5:57 PM, Simon Wright wrote: > "Nasser M. Abbasi" <nma@12000.org> writes: > I've updated the adablas project (leaving out the test/ executables that > had made their way into the zip file!) thanks Simon. >but am unsure about the adalapack > project; there are quite a lot of files named, or in directories named, > OLD. Also, I don't think the convert/ directory is useful any more? > Please advise. > I kept all the original packages in there, before I merged them into one.I put them in an OLD directory. This can be removed. not needed. The convert folder is very important. It is what Dr Wasu Chaopanon used to generate the bindings from Fortran! They are perl scripts. If someone wants to update and add more Lapack API's (not all the calls are there now), then may be these can be used again). No harm of keeping them there. > I can see that people using GPS would want to use git (or svn, or even > cvs) because GPS supports them, and doesn't support hg. But I still > think that git is far more complex than most people need. We are not > Linus Torvalds! > I really do not know anything about git or HG. I did not see HG when I created the project. If you know how to change this, feel free to do that. You are the expert on these things, I never used any of this that is why I asked for help in setting this up somewhere. regards, --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 23:09 ` Nasser M. Abbasi @ 2012-08-20 23:31 ` Simon Wright 0 siblings, 0 replies; 41+ messages in thread From: Simon Wright @ 2012-08-20 23:31 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > On 8/20/2012 5:57 PM, Simon Wright wrote: >> "Nasser M. Abbasi" <nma@12000.org> writes: >> but am unsure about the adalapack >> project; there are quite a lot of files named, or in directories named, >> OLD. Also, I don't think the convert/ directory is useful any more? >> Please advise. > > I kept all the original packages in there, before I merged them > into one.I put them in an OLD directory. This can be removed. > not needed. OK > The convert folder is very important. It is what Dr Wasu Chaopanon > used to generate the bindings from Fortran! They are perl scripts. > If someone wants to update and add more Lapack API's (not all the > calls are there now), then may be these can be used again). No > harm of keeping them there. OK (I was misled by the README, which mentions an absent file MakeAda). >> I can see that people using GPS would want to use git (or svn, or >> even cvs) because GPS supports them, and doesn't support hg. But I >> still think that git is far more complex than most people need. We >> are not Linus Torvalds! > > I really do not know anything about git or HG. I did not see HG when I > created the project. If you know how to change this, feel free to do > that. You are the expert on these things, I never used any of this > that is why I asked for help in setting this up somewhere. As I said, GPS users would want to use git (mind you, I haven't looked at the GPS git interface). I will shut up and suck it up now. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-20 15:03 ` Nasser M. Abbasi 2012-08-20 22:57 ` Simon Wright @ 2012-08-21 10:44 ` Simon Wright 2012-08-21 14:50 ` Nasser M. Abbasi 1 sibling, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-08-21 10:44 UTC (permalink / raw) "Nasser M. Abbasi" <nma@12000.org> writes: > https://sourceforge.net/p/adalapack/wiki/Home/ I've now uploaded this. I retained the INSTALL and README files and the doc directory, removing the .OLD part, because they will be a good thing to have after they've been updated. The 'proper' entry points to the two projects are https://sourceforge.net/projects/adablas/ https://sourceforge.net/projects/adalapack/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-21 10:44 ` Simon Wright @ 2012-08-21 14:50 ` Nasser M. Abbasi 0 siblings, 0 replies; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-21 14:50 UTC (permalink / raw) On 8/21/2012 5:44 AM, Simon Wright wrote: > > The 'proper' entry points to the two projects are > > https://sourceforge.net/projects/adablas/ > https://sourceforge.net/projects/adalapack/ > Thank you Simon for your help. I never used this system before, but I assume if any one wants to make changes to the source code needs to be added to the project. If so, they can can contact me or Simon and will add them there. Now we have an official home for Ada Blas and Ada Lapack binding. This is good for Ada. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 20:45 ` Niklas Holsti 2012-08-18 21:46 ` Simon Wright @ 2012-08-18 22:51 ` Nasser M. Abbasi 2012-08-18 23:16 ` Niklas Holsti 1 sibling, 1 reply; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-18 22:51 UTC (permalink / raw) 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. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 22:51 ` Nasser M. Abbasi @ 2012-08-18 23:16 ` Niklas Holsti 2012-08-18 23:40 ` Nasser M. Abbasi 0 siblings, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-08-18 23:16 UTC (permalink / raw) 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 23:16 ` Niklas Holsti @ 2012-08-18 23:40 ` Nasser M. Abbasi 2012-08-19 7:50 ` Niklas Holsti 0 siblings, 1 reply; 41+ messages in thread From: Nasser M. Abbasi @ 2012-08-18 23:40 UTC (permalink / raw) 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. It is true that a user writing A(2,1) does not care how the compiler calculates the linear address of the second row, first column entry, but this assumes the data is already there in the correct layout. If I call Fortran from Ada and Fortran returns a matrix back, it will be in the wrong order in memory as far as how Ada looks at it. So someone needs to rest the layout right? I could be missing something. I am no expert at all in this. I actually program in Mathematica and Matlab and not in Ada nor in Fortran but it is good to find the reason if it is not the memory layout issue. --Nasser ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 23:40 ` Nasser M. Abbasi @ 2012-08-19 7:50 ` Niklas Holsti 0 siblings, 0 replies; 41+ messages in thread From: Niklas Holsti @ 2012-08-19 7:50 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-18 16:33 ` Ada novice 2012-08-18 17:32 ` Simon Wright 2012-08-18 20:45 ` Niklas Holsti @ 2012-08-19 2:20 ` Leo Brewin 2 siblings, 0 replies; 41+ messages in thread From: Leo Brewin @ 2012-08-19 2:20 UTC (permalink / raw) I wrote the Ada_Lapack for my own needs. It was never my intention to merge Annex G.3 with Lapack. All I need from Ada_Lapck is access to the Lapack codes. Any other operations on matrices can easily be handled by Annex G. I agree, I don't want to "re-invent the wheel", it's already there (Annex G.3). I don't consider myself an Ada programmer, I just happen to use it for my work. I started using it earlier this year and I think it is a fantastic language, perfect for serious scientific computations. Leo ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: ada lapack 2012-08-17 13:45 ` Leo Brewin 2012-08-17 14:11 ` Marc C @ 2012-08-17 14:12 ` Brian Drummond 1 sibling, 0 replies; 41+ messages in thread From: Brian Drummond @ 2012-08-17 14:12 UTC (permalink / raw) On Fri, 17 Aug 2012 06:45:42 -0700, Leo Brewin wrote: > I've just returned from watching my football team lose (again), that was > the bad news. > The good news is that Niklas did my job for me -- solving the problems > with the errant Makefile. Thanks Niklas. I had assumed that everybody > would have . in their path. Is this a reasonable assumption? But just to > be on the safe side I'll update the Makefile. A lot of Linux distributions don't have . in the path, by default. - Brian ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-08-21 14:50 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-15 6:16 ada lapack Leo Brewin 2012-08-16 3:34 ` Jerry 2012-08-17 6:25 ` Ada novice 2012-08-17 7:11 ` Leo Brewin 2012-08-17 7:42 ` Ada novice 2012-08-17 9:43 ` Niklas Holsti 2012-08-17 10:27 ` Ada novice 2012-08-17 11:08 ` Niklas Holsti 2012-08-17 11:33 ` Ada novice 2012-08-17 13:45 ` Leo Brewin 2012-08-17 14:11 ` Marc C 2012-08-18 11:57 ` Ada novice 2012-08-18 13:13 ` Niklas Holsti 2012-08-18 13:48 ` Ada novice 2012-08-18 15:22 ` Nasser M. Abbasi 2012-08-18 16:33 ` Ada novice 2012-08-18 17:32 ` Simon Wright 2012-08-18 17:44 ` Nasser M. Abbasi 2012-08-18 20:45 ` Niklas Holsti 2012-08-18 21:46 ` Simon Wright 2012-08-19 2:24 ` Leo Brewin 2012-08-19 5:39 ` Ada novice 2012-08-19 7:10 ` Leo Brewin 2012-08-19 13:02 ` Simon Wright 2012-08-20 14:05 ` Nasser M. Abbasi 2012-08-20 14:57 ` Simon Wright 2012-08-20 15:10 ` Nasser M. Abbasi 2012-08-20 18:09 ` Ada novice 2012-08-20 18:46 ` Nasser M. Abbasi 2012-08-20 15:03 ` Nasser M. Abbasi 2012-08-20 22:57 ` Simon Wright 2012-08-20 23:09 ` Nasser M. Abbasi 2012-08-20 23:31 ` Simon Wright 2012-08-21 10:44 ` Simon Wright 2012-08-21 14:50 ` Nasser M. Abbasi 2012-08-18 22:51 ` Nasser M. Abbasi 2012-08-18 23:16 ` Niklas Holsti 2012-08-18 23:40 ` Nasser M. Abbasi 2012-08-19 7:50 ` Niklas Holsti 2012-08-19 2:20 ` Leo Brewin 2012-08-17 14:12 ` Brian Drummond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox