How to initialize a matrix of one column only?

So trivial, yet Ada is giving me hard time with this
because I am a newbie.

I am trying to call SGESV in Lapack

http://www.netlib.org/lapack/single/sgesv.f

One of the arguments must be a matrix (the 'B' argument there).

I want to pass it a one column matrix. (i.e. I can't use a
Vector, it must be a matrix, since this is what the Ada Lapack
binding requires).

But I can't get the syntax to simply initialize the required
matrix to be a one column matrix. I keep getting the error

nested array aggregate expected

I am sure this is trivial, but after tried all the
combinations I can think of, and googling around, I
give up. It works with the B matrix is (1..N,1..N)
but not when I write it as (1..N,1..1) to make it one
column matrix.

Here is the code, I write

----------------------
with Interfaces.Fortran;
use Interfaces.Fortran;
with lbase;
....
N: Fortran_Integer := 3;
B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
BEGIN
B := ((9.0) , -- here is the problem
(2.0) ,
(-2.0));
....
--------------------------------------------

where the labase package simply introduces a type for
Fortran_Real_Matrix as follows

----------------------------
type Fortran_Real_Matrix is array (Fortran_Integer range <>,
Fortran_Integer range <>)
of Real;
pragma Convention (Fortran, Fortran_Real_Matrix);
--------------------


>gnatmake -I../ada lap42.adb
gcc -c -I../ada lap42.adb
lap42.adb:35:16: nested array aggregate expected
lap42.adb:35:16: if single-component aggregate is intended, write e.g. (1 => ...)
gnatmake: "lap42.adb" compilation error
>

I tried B:=(1=>9.0,2=>2.03=>-2.0);
and B := ((9.0 ,2.0 , 3));
but non working.

What is the correct syntax to use?

thanks,
--Nasser

On 7/7/2012 7:08 PM, Nasser M. Abbasi wrote:

> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));
> ....
> --------------------------------------------
.....
>
> I tried B:=(1=>9.0,2=>2.03=>-2.0);
> and B := ((9.0 ,2.0 , 3));
> but non working.
>
> What is the correct syntax to use?
>

I found it !

But it makes no sense at al to me. Here is the correct syntax

------------------
N: Fortran_Integer := 3;
B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
BEGIN
B := ((9.0, others=>0.0),
(2.0, others=>0.0),
(-2.0, others=>0.0)
);
----------------------

Why do I have to write others=>0.0 ? What others? there is
only 1 column? What Am I missing here?

--Nasser

In article <jtaj2c$18k$1@speranza.aioe.org>,
"Nasser M. Abbasi" <nma@12000.org> wrote:
[...]
> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));
> ....
> --------------------------------------------
>
> where the labase package simply introduces a type for
> Fortran_Real_Matrix as follows
>
> ----------------------------
> type Fortran_Real_Matrix is array (Fortran_Integer range <>,
> Fortran_Integer range <>)
> of Real;
> pragma Convention (Fortran, Fortran_Real_Matrix);
> --------------------
>
>
> >gnatmake -I../ada lap42.adb
> gcc -c -I../ada lap42.adb
> lap42.adb:35:16: nested array aggregate expected
> lap42.adb:35:16: if single-component aggregate is intended, write e.g. (1 =>
> ...)
> gnatmake: "lap42.adb" compilation error
> >
>
> I tried B:=(1=>9.0,2=>2.03=>-2.0);
> and B := ((9.0 ,2.0 , 3));
> but non working.
>
> What is the correct syntax to use?

According to 4.3.3 Array Aggregates, you need to use named notation for
a single component, otherwise "a single expression in parentheses is
interpreted as a parenthesized expression."

B := ((1 => 9.0),
(1 => 2.0),
(1 => -2.0));

<http://www.ada-auth.org/standards/12rm/html/RM-4-3-3.html>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 7/7/2012 8:47 PM, John B. Matthews wrote:
.....
>> I tried B:=(1=>9.0,2=>2.03=>-2.0);
....
>>
>> What is the correct syntax to use?
>
> According to 4.3.3 Array Aggregates, you need to use named notation for
> a single component, otherwise "a single expression in parentheses is
> interpreted as a parenthesized expression."
>
> B := ((1 => 9.0),
> (1 => 2.0),
> (1 => -2.0));
>
> <http://www.ada-auth.org/standards/12rm/html/RM-4-3-3.html>
>

Thanks John. I think I did browse some of these RM notes, but
I either missed it or did not understand it (sometimes
the RM writing is hard to understand for me).

But the above is a good example of why Ada has the
reputation of being too verbose.

Compare the above to Matlab for example to make
a matrix of one column

B=[9 2 -2]'

or Mathematica

B={{9},{2},{-2}}

But I guess on the other hand, one gets the strong typing
as a payback for all this extra typing. So may be one can't
complain too much.

regards,
--Nasser

"Nasser M. Abbasi" <nma@12000.org> writes:

> I want to pass it a one column matrix. (i.e. I can't use a
> Vector, it must be a matrix, since this is what the Ada Lapack
> binding requires).

The case where NRHS is 1 probably happens often enough that it deserves
its own overlaid binding (this is what the Ada Solve has).

From the point of view of SGESV's object code, there's no difference
between a (1 .. n, 1 .. 1) matrix and a (1 .. n) vector.

"Nasser M. Abbasi" <nma@12000.org> writes:

> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));

There is an ambiguity in Ada syntax; a parenthesized expression looks
like a one-element aggregate. To distinguish the two cases, you must use
named association for one-element aggregates:

B := ((1 => 9.0) , -- here is the problem
(1 => 2.0) ,
(1 => -2.0));

--
-- Stephe

On Sat, 07 Jul 2012 21:09:56 -0500, Nasser M. Abbasi wrote:

> On 7/7/2012 8:47 PM, John B. Matthews wrote:
> ....
>>> I tried B:=(1=>9.0,2=>2.03=>-2.0);
> ...
>>>
>>> What is the correct syntax to use?
>>
>> According to 4.3.3 Array Aggregates, you need to use named notation for
>> a single component, otherwise "a single expression in parentheses is
>> interpreted as a parenthesized expression."
>>
>> B := ((1 => 9.0),
>> (1 => 2.0), (1 => -2.0));

> But the above is a good example of why Ada has the reputation of being
> too verbose.

To be fair, Ada is not always so verbose; a 1-column array is an unusual
case.

If you need to write this more than once, I would try to abstract out the
ugliness with a function taking a vector and returning the 1-column
equivalent. For an initialisation, I would be surprised if there was any
overhead at all...

- Brian

On Jul 7, 5:08*pm, "Nasser M. Abbasi" <n...@12000.org> wrote:

> where the labase package simply introduces a type for
> Fortran_Real_Matrix as follows
>
> ----------------------------
> * *type Fortran_Real_Matrix is array (Fortran_Integer range <>,
> * * * * * * * * * * * * * * * * * * * Fortran_Integer range <>)
> * * * * * of Real;
> * * *pragma Convention (Fortran, Fortran_Real_Matrix);

I wish these bindings would be rewritten to use Annex G.3 Real_Vector
and Real_Matrix (etc. for complex) so that a single set of types can
be used in a program that uses the G.3 stuff anyway.

Jerry

Jerry <lanceboyle@qwest.net> writes:

> On Jul 7, 5:08Â*pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
>
>> where the labase package simply introduces a type for
>> Fortran_Real_Matrix as follows
>>
>> ----------------------------
>> Â* Â*type Fortran_Real_Matrix is array (Fortran_Integer range <>,
>> Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Fortran_Integer range <>)
>> Â* Â* Â* Â* Â* of Real;
>> Â* Â* Â*pragma Convention (Fortran, Fortran_Real_Matrix);
>
> I wish these bindings would be rewritten to use Annex G.3 Real_Vector
> and Real_Matrix (etc. for complex) so that a single set of types can
> be used in a program that uses the G.3 stuff anyway.

The problem with that is that the BLAS is a Fortran library, so expects
Fortran conventions for matrices. The Ada_BLAS bindings are thin, so
don't do the transposition required .

The old GNAT Ada.Numerics.Generic_{Real,Complex}_Arrays did the
transposition explicitly.

There was a discussion about this (and performance aspects) on this
group:
http://groups.google.com/group/comp....bcbb133b8d5a62

On Jul 9, 2:35*am, Simon Wright <si...@pushface.org> wrote:
> > I wish these bindings would be rewritten to use Annex G.3 Real_Vector
> > and Real_Matrix (etc. for complex) so that a single set of types can
> > be used in a program that uses the G.3 stuff anyway.
>
> The problem with that is that the BLAS is a Fortran library, so expects
> Fortran conventions for matrices. The Ada_BLAS bindings are thin, so
> don't do the transposition required .
>
> The old GNAT Ada.Numerics.Generic_{Real,Complex}_Arrays did the
> transposition explicitly.
>
> There was a discussion about this (and performance aspects) on this
> group:http://groups.google.com/group/comp..../thread/5395b8...

OS X ships with both Fortran and C versions of BLAS and LAPACK, so I
would suppose the C version is common. Wouldn't using the C versions
solve this problem? As I recall, both Ada and C are row major.

Jerry

Jerry <lanceboyle@qwest.net> writes:

> OS X ships with both Fortran and C versions of BLAS and LAPACK, so I
> would suppose the C version is common. Wouldn't using the C versions
> solve this problem? As I recall, both Ada and C are row major.

I just rebuilt my gnat-math-extn unit tests with libclapack, libcblas
and they run successfully without any change to my bindings. So I think
the C versions must retain the same column-major ordering as the Fortran
ones.

Oh. No surprise there, because /usr/lib/libblas.dylib and
/usr/lib/libcblas.dylib are symlinks to the same file!

"Nasser M. Abbasi" <nma@12000.org> writes:

> Thanks John. I think I did browse some of these RM notes, but
> I either missed it or did not understand it (sometimes
> the RM writing is hard to understand for me).

Trying to learn Ada by reading the RM is not a good idea
-- it is indeed hard to understand. Read a textbook first.
I like Barnes, but there are others.

> But I guess on the other hand, one gets the strong typing
> as a payback for all this extra typing. So may be one can't
> complain too much.

Sometimes verbosity gives you strong typing, but requiring
named notation for one-element aggregates gives you nothing
-- it's just bad language design. Even more so for zero-element
aggregates.

- Bob

If you want to save all but one of these annoying "1 => ", you can make a line matrix and transpose, like you did in Matlab: B=[9 2 -2]' (of course more verbose):

Transpose( (1=> (9.0, 2.0, -2.0)) )

_________________________
Gautier's Ada programming
http://sf.net/users/gdemont/

On Thursday, July 12, 2012 1:50:42 AM UTC-7, Simon Wright wrote:
> Jerry; writes:
>
> &gt; OS X ships with both Fortran and C versions of BLAS and LAPACK, so I
> &gt; would suppose the C version is common. Wouldn't using the C versions
> &gt; solve this problem? As I recall, both Ada and C are row major.
>
> I just rebuilt my gnat-math-extn unit tests with libclapack, libcblas
> and they run successfully without any change to my bindings. So I think
> the C versions must retain the same column-major ordering as the Fortran
> ones.

Oh well. Thanks for checking into that. Still, it seems odd. It must make life hard for C coders who link to these libs. I would have thought that (compatible ordering) would be a big reason for rewriting in C.
>
> Oh. No surprise there, because /usr/lib/libblas.dylib and
> /usr/lib/libcblas.dylib are symlinks to the same file!

Yes. I noticed that some time back. (OS X, right?) But I think these libs contain both Fortran and C versions.

Jerry <lanceboyle@qwest.net> writes:

> On Thursday, July 12, 2012 1:50:42 AM UTC-7, Simon Wright wrote:
>> Jerry; writes:
>>
>> > OS X ships with both Fortran and C versions of BLAS and LAPACK, so I
>> > would suppose the C version is common. Wouldn't using the C versions
>> > solve this problem? As I recall, both Ada and C are row major.
>>
>> I just rebuilt my gnat-math-extn unit tests with libclapack, libcblas
>> and they run successfully without any change to my bindings. So I think
>> the C versions must retain the same column-major ordering as the Fortran
>> ones.
>
> Oh well. Thanks for checking into that. Still, it seems odd. It must
> make life hard for C coders who link to these libs. I would have
> thought that (compatible ordering) would be a big reason for rewriting
> in C.

http://www.netlib.org/clapack/readme says that the CLAPACK bindings were
produced by f2c (and human post-processing) from the LAPACK Fortran, and
that you are stuck with Fortran conventions.

However, CBLAS appears to be a proper interface; each cblas_* function
has a leading 'ordering' parameter.

>> Oh. No surprise there, because /usr/lib/libblas.dylib and
>> /usr/lib/libcblas.dylib are symlinks to the same file!
>
> Yes. I noticed that some time back. (OS X, right?) But I think these
> libs contain both Fortran and C versions.

Very odd. 'nm liblapack.dylib' results in, for example,

0000000000017591 T _cgeev
0000000000017591 T _cgeev_

where the version with the trailing underscore is what gfortran would
produce natively. The other would work for languages that can't generate
symbols with trailing underscores. But they both represent the same
address!

They also appear in upper case (again, same address).

libblas.dylib contains the cblas_* symbols.