ada lapack

ada lapack

[Leo Brewin]

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

Re: ada lapack

[Jerry]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Leo Brewin]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Leo Brewin]

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

Re: ada lapack

[Marc C]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Simon Wright]

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!

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Simon Wright]

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 :-(

Re: ada lapack

[Leo Brewin]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Leo Brewin]

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

Re: ada lapack

[Simon Wright]

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).

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Simon Wright]

"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?

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Ada novice]

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

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Simon Wright]

"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!

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Simon Wright]

"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.

Re: ada lapack

[Simon Wright]

"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/

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Nasser M. Abbasi]

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

Re: ada lapack

[Niklas Holsti]

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
      .      @       .

Re: ada lapack

[Leo Brewin]

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

Re: ada lapack

[Brian Drummond]

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