comp.lang.ada
 help / color / mirror / Atom feed
* Lapack Ada binding matrices/vectors issue, how to best to resolve?
@ 2012-07-12  0:38 Nasser M. Abbasi
  2012-07-12  0:45 ` Nasser M. Abbasi
  2012-07-12 12:35 ` Georg Bauhaus
  0 siblings, 2 replies; 3+ messages in thread
From: Nasser M. Abbasi @ 2012-07-12  0:38 UTC (permalink / raw)



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

http://www.ada-auth.org/standards/12rm/html/RM-G-3-1.html

What this means, is that one can't even multiply a number by the
matrix if the Matrix is Fortran_Real_Matrix like one can with
Real_Matrix. Here is a simple example

---------------------------
with Interfaces.Fortran; use Interfaces.Fortran;
with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
with labase; use labase;  -- LAPACK binding

procedure foo3 is
      
   A1 : constant Fortran_Real_Matrix(1..2,1..2):=
         12.0*((12.0,  6.0),(-12.0, 6.0)); -- ERROR
          
   A2 : constant Real_Matrix(1..2,1..2) :=
          12.0*((12.0,  6.0),(-12.0,  6.0)); -- OK
   begin
     null;
end foo3;
--------------------

>gnatmake -gnat2012 -I/lapada/ada  foo2.adb -largs -lblas
gcc -c -gnat2012 -I/lapada/ada foo2.adb
foo2.adb:24:20: expected type "Fortran_Real_Matrix" defined at labase.ads:94
foo2.adb:24:20: found type "Interfaces.Fortran.Complex"
gnatmake: "foo2.adb" compilation error
>

I tried to do conversion of the Fortran_Real_Matrix to
Real_Matrix but the compiler does not like it as it is
aggregate.

So, this means this binding as it stands is too limited to
use as is.

What would be a good way to fix this whole issue? Make a
pacakge similar to Numerics.Generic_Real_Arrays for
the Fortran_Real_Matrix so that all the operators '*','+', etc..
are available now for this Matrix type?

The Ada lapack package with's :

with Ada.Numerics.Generic_Complex_Types;
with Interfaces.Fortran; use  Interfaces.Fortran;

Then it defines many types, such as
----------------------
type Fortran_Integer_Matrix is array (Fortran_Integer range <>,
                                       Fortran_Integer range <>)
          of Fortran_Integer;
pragma Convention (Fortran, Fortran_Integer_Matrix);
etc..
----------------------

But it does NOT define operators to work on these types like
the Ada package Ada.Numerics.Real_Arrays  does:

-------------------------------
function "*" (Left : Real'Base;   Right : Real_Matrix)
       return Real_Matrix;
---------------------------

I was thinking of just copying all these functions as the above to the
Lapack package and edit things and change all the Real_Matrix to
Fortran_Real_Matrix etc..  but this seems like not the right way
to do this.

The main Lapack package is lapada/ada/labase.ads in
the tar file

ftp://ftp.cs.kuleuven.be/pub/Ada-Belgium/mirrors/gnu-ada/OLD/contrib/lapack-ada/

Any suggestion how to resolve this from experts will be great as I am
a newbie in Ada.

--Nasser




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Lapack Ada binding matrices/vectors issue, how to best to resolve?
  2012-07-12  0:38 Lapack Ada binding matrices/vectors issue, how to best to resolve? Nasser M. Abbasi
@ 2012-07-12  0:45 ` Nasser M. Abbasi
  2012-07-12 12:35 ` Georg Bauhaus
  1 sibling, 0 replies; 3+ messages in thread
From: Nasser M. Abbasi @ 2012-07-12  0:45 UTC (permalink / raw)


On 7/11/2012 7:38 PM, Nasser M. Abbasi wrote:
>
> ---------------------------
> with Interfaces.Fortran; use Interfaces.Fortran;
> with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
> with labase; use labase;  -- LAPACK binding
>
> procedure foo3 is
>
>     A1 : constant Fortran_Real_Matrix(1..2,1..2):=
>           12.0*((12.0,  6.0),(-12.0, 6.0)); -- ERROR
>
>     A2 : constant Real_Matrix(1..2,1..2) :=
>            12.0*((12.0,  6.0),(-12.0,  6.0)); -- OK
>     begin
>       null;
> end foo3;
> --------------------
>

opps that should be foo3.adb in the command below (I copied the file content
to new file and named it foo3, but pasted the older command on the window which
was foo2.adb)

>> gnatmake -gnat2012 -I/lapada/ada  foo2.adb -largs -lblas
> gcc -c -gnat2012 -I/lapada/ada foo2.adb
> foo2.adb:24:20: expected type "Fortran_Real_Matrix" defined at labase.ads:94
> foo2.adb:24:20: found type "Interfaces.Fortran.Complex"
> gnatmake: "foo2.adb" compilation error
>>
>

here is the command again:

>gnatmake -gnat2012 -I/lapada/ada  foo3.adb -largs -lblas
gcc -c -gnat2012 -I/lapada/ada foo3.adb
foo3.adb:10:13: expected type "Fortran_Real_Matrix" defined at labase.ads:94
foo3.adb:10:13: found type "Complex_Star_16" defined at labase.ads:52
gnatmake: "foo3.adb" compilation error
>

(I just did not want someone to get confused if they saw this).

--Nasser




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Lapack Ada binding matrices/vectors issue, how to best to resolve?
  2012-07-12  0:38 Lapack Ada binding matrices/vectors issue, how to best to resolve? Nasser M. Abbasi
  2012-07-12  0:45 ` Nasser M. Abbasi
@ 2012-07-12 12:35 ` Georg Bauhaus
  1 sibling, 0 replies; 3+ messages in thread
From: Georg Bauhaus @ 2012-07-12 12:35 UTC (permalink / raw)


On 12.07.12 02:38, Nasser M. Abbasi wrote:
> 
> What would be a good way to fix this whole issue?

First, describe the issue in terms of a sufficient
number of needs, also a sufficient number of programmers
with such needs, while remembering that Ada uses building
blocks all over the place.

Second, consider Ada a general purpose programming
language that allows addressing things in the small,
unlike Mathematica, or Octave.

Third, consider, and formalize, the characteristics
of the operators and operations, such that their innate
importance becomes apparent. For example, computing
in science extends into areas where Euclidean geometry is
almost never used, where the distance used is the abstract
city block distance (not measured in meters or feet),
where operators are from statistics, etc., but you'd still
be using arrays a lot.

Forth, should these operators allow different implementations
to be selected by the programmer to match his or her program's
need?

Fifth, if there were a library of operator definitions,
such as multiplying an array by a scalar, or a container by
a scalar, would it be enough?





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-07-12 12:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-12  0:38 Lapack Ada binding matrices/vectors issue, how to best to resolve? Nasser M. Abbasi
2012-07-12  0:45 ` Nasser M. Abbasi
2012-07-12 12:35 ` Georg Bauhaus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox