Any easy/build-in construct to extract submatrices from larger matrix?

Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

Given square matrix, say 3 by 3 real matrix, and we
want to extract a submatrix from it, a 2 by 2 submatrix,
which is found by removing column and row given by
index I and J.

For example, given

  A : constant Real_Matrix :=
              (( 1.0,  2.0,  3.0),
               ( 4.0,  5.0,  6.0),
               ( 7.0,  8.0,  9.0));

and I=1, J=1, then the submatrix to extract is

                  5 6
                  8 9

because we removed row I=1, and column J=1, and what
is left is what is needed.

Ofcourse I can code it the hard way, using lots of if's,
and loops, and build the submatrix by hand, one row/column at
a time. But I wanted to see if there is a build-in
easy way, like slicing off a row and column off a matrix
on the fly.

Here is a skeleton code if someone wants to give this a try

---------------------------------------------
with Ada.Text_Io; use Ada.Text_Io;
with Ada.Float_Text_Io; use Ada.Float_Text_Io;
with Ada.Numerics.Real_Arrays;  use Ada.Numerics.Real_Arrays;

procedure foo is
     A : constant Real_Matrix :=
              (( 1.0,  2.0,  3.0),
               ( 4.0,  5.0,  6.0),
               ( 7.0,  8.0,  9.0));
     B : real_matrix(1 .. 2, 1 .. 2);

begin

     FOR I in A'range(1) LOOP
       FOR J in A'range(2) LOOP
           --B := -- ??? smart way to do this?
           put(A(I,J));
       END LOOP;
       new_line;
     END LOOP;

end foo;
--------------------------------

fyi, modern Fortran has a nice facility to do this, called
pack(). It works like this: make up a MASK matrix of same size
as A. For those elements we want removed, put in a logical
.false at that location.

Hence, to extract column 1 say from A, build up a MASK matrix
with .false. in each element of the first column, then call
PACK() with this mask and A. Then PACK() return all elements
of A that has corresponding .true. in the MASK.

So, the above in Fortran works like this:

--------------------------------------------------
program t46
implicit none

integer, parameter :: n=3
integer :: i,j
real (kind=kind(0.0d0)) :: A(n,n),B(n-1,n-1)
logical :: mask(n,n)
  
A(1,:) = [1, 2, 3];
A(2,:) = [4, 5, 6];
A(3,:) = [7, 8, 9];

DO j=1,n
    DO i=1,n
       
       mask = .true.
       mask(:,j) = .false.
       mask(i,:) = .false.
       
       !-- extract submatrix (looking for Ada equivalent)
       B = reshape(pack(A, mask),[n-1,n-1])
       
       write(*,'(2F6.1)') B
       print *,'------------'
       
    END DO
END DO
end program t46
------------------------------

>gfortran -fcheck=all -Wall t46.f90
>./a.out
    5.0   8.0
    6.0   9.0
  ------------
    2.0   8.0
    3.0   9.0
  ------------
    2.0   5.0
    3.0   6.0
  ------------
    4.0   7.0
    6.0   9.0
  ------------
    1.0   7.0
    3.0   9.0
  ------------
    1.0   4.0
    3.0   6.0
  ------------
    4.0   7.0
    5.0   8.0
  ------------
    1.0   7.0
    2.0   8.0
  ------------
    1.0   4.0
    2.0   5.0
  ------------
>


I have googled on-line looking for something build-in, but
so far, no luck. But will continue searching...

thanks,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Sun, 24 Jun 2012 03:05:37 -0500, Nasser M. Abbasi wrote:

> fyi, modern Fortran has a nice facility to do this, called
> pack(). It works like this: make up a MASK matrix of same size
> as A. For those elements we want removed, put in a logical
> .false at that location.

This looks like a low-level hack with unpredictable results, because it
does not specify the dimensions and the order of the elements for the
result matrix.

If I implemented indicator functions for matrices, with the thingy is, I
would define an abstract type with multiple implementations including a set
of indices. A set would be far more effective for sparse matrices than
Boolean matrix.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/24/2012 3:24 AM, Dmitry A. Kazakov wrote:
> On Sun, 24 Jun 2012 03:05:37 -0500, Nasser M. Abbasi wrote:
>
>> fyi, modern Fortran has a nice facility to do this, called
>> pack(). It works like this: make up a MASK matrix of same size
>> as A. For those elements we want removed, put in a logical
>> .false at that location.
>
> This looks like a low-level hack with unpredictable results, because it
> does not specify the dimensions and the order of the elements for the
> result matrix.
>

Pack() returns a vector, not a matrix. That is why reshape() is used.
The order is well defined. Fortran uses Fortran order? (column major).
So I am not sure I understand your "unpredictable results" ?

> If I implemented indicator functions for matrices, with the thingy is, I
> would define an abstract type with multiple implementations including a set
> of indices. A set would be far more effective for sparse matrices than
> Boolean matrix.
>

Well. Sounds too advanced for me. I was just looking for a little more
simple solution.

btw, if you think the Fortran solution was short, in Matlab,
this is done like this

EDU>> A=[1 2 3;4 5 6;7 8 9];
EDU>> A(1,:)=[];   % removes row 1
EDU>> A(:,1)=[]    % removes column 1

A =
      5     6
      8     9

And this would also work if A was sparse in Matlab.

regards,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Sun, 24 Jun 2012 03:55:08 -0500, Nasser M. Abbasi wrote:

> On 6/24/2012 3:24 AM, Dmitry A. Kazakov wrote:
>> On Sun, 24 Jun 2012 03:05:37 -0500, Nasser M. Abbasi wrote:
>>
>>> fyi, modern Fortran has a nice facility to do this, called
>>> pack(). It works like this: make up a MASK matrix of same size
>>> as A. For those elements we want removed, put in a logical
>>> .false at that location.
>>
>> This looks like a low-level hack with unpredictable results, because it
>> does not specify the dimensions and the order of the elements for the
>> result matrix.
>>
> 
> Pack() returns a vector, not a matrix. That is why reshape() is used.
> The order is well defined. Fortran uses Fortran order? (column major).
> So I am not sure I understand your "unpredictable results" ?

Exactly this.

Ada's equivalent would be arrays of aliased elements + pointer arithmetic.
An alternative is, again, a pointer + unchecked conversion + renaming to
whatever array type.

>> If I implemented indicator functions for matrices, with the thingy is, I
>> would define an abstract type with multiple implementations including a set
>> of indices. A set would be far more effective for sparse matrices than
>> Boolean matrix.
> 
> Well. Sounds too advanced for me.

Not advanced. An advanced solution is to have the whole set of index and
matrix types with the corresponding operations. Ada's type system is not
yet capable to handle this.

> I was just looking for a little more simple solution.

I don't find indicator Boolean matrix + array representation hack simple. 

And to me the problem is not clear. Are you writing a concrete program or
considering a proper way to model matrix lattices in a strongly typed
programming language? The difference is huge.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/24/2012 6:10 AM, Dmitry A. Kazakov wrote:

> And to me the problem is not clear. Are you writing a concrete program or
> considering a proper way to model matrix lattices in a strongly typed
> programming language? The difference is huge.
>
>

Dmitry;

I was try to implement, just for fun, finding the adjungate
matrix, using the direct algorithm using Ada, as shown here:

http://en.wikipedia.org/wiki/Adjugate_matrix

it requires finding the cofactors of each element in a 2D matrix.

Hence needed a simply way to obtain a submatrix from the main
matrix. I understand that slices are not supported for 2D matrices
in Ada. Only for 1D.

I think something like pack() (and unpack()) functions would be
useful to have in Ada:

http://fortranwiki.org/fortran/show/pack

pack() allows one to extract rows/columns, not necessarily
in sequence, out of a matrix using a mask matrix. This is
very useful for many linear algebra operations on matrices.

thanks,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Sun, 24 Jun 2012 07:16:50 -0500, Nasser M. Abbasi wrote:

> On 6/24/2012 6:10 AM, Dmitry A. Kazakov wrote:
> 
>> And to me the problem is not clear. Are you writing a concrete program or
>> considering a proper way to model matrix lattices in a strongly typed
>> programming language? The difference is huge.
>>
> I was try to implement, just for fun, finding the adjungate
> matrix, using the direct algorithm using Ada, as shown here:
> 
> http://en.wikipedia.org/wiki/Adjugate_matrix
> 
> it requires finding the cofactors of each element in a 2D matrix.

I suppose that there exist much better numerical methods than doing this as
described in the definition.

> Hence needed a simply way to obtain a submatrix from the main
> matrix.

If you want a function which would return a submatrix obtained by removing
the row I and column J:

function Exclude (A : Complex_Matrix; I, J : Integer)
   return Complex_Matrix is
   AI, AJ : Integer := A'First (1);
begin
   return B : Complex_Matrix (1..A'Length (1)-1, 1..A'Length (2)-1) do
      AI := A'First (1);
      for BI in B'Range (1) loop
         if AI = I then
            AI := AI + 1;
         end if;
         AJ := A'First (2);
         for BJ in B'Range (2) loop
            if AJ = J then
               AJ := AJ + 1;
            end if;
            B (BI, BJ) := A (AI, AJ); 
            AJ := AJ + 1;
         end loop;
         AI := AI + 1;
      end loop;
   end return;
end Exclude;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/24/2012 11:11 AM, Dmitry A. Kazakov wrote:
> On Sun, 24 Jun 2012 07:16:50 -0500, Nasser M. Abbasi wrote:
>
>> On 6/24/2012 6:10 AM, Dmitry A. Kazakov wrote:
>>
>>> And to me the problem is not clear. Are you writing a concrete program or
>>> considering a proper way to model matrix lattices in a strongly typed
>>> programming language? The difference is huge.
>>>
>> I was try to implement, just for fun, finding the adjungate
>> matrix, using the direct algorithm using Ada, as shown here:
>>
>> http://en.wikipedia.org/wiki/Adjugate_matrix
>>
>> it requires finding the cofactors of each element in a 2D matrix.
>
> I suppose that there exist much better numerical methods than doing this as
> described in the definition.
>

Yes, I am sure of this. But it is just for learning purposes.

> If you want a function which would return a submatrix obtained by removing
> the row I and column J:
>

Thanks, Will try it out! You are good in Ada, so can write functions
like this as needed quickly. I think Ada should add more
support for more build-in type functions for matrix/vector operations.

At least, 2D slicing of arrays should be possible? If not, that
mask/pack functionality as in Fortran, should be present in Ada
as part of the library.

> function Exclude (A : Complex_Matrix; I, J : Integer)
>     return Complex_Matrix is
>     AI, AJ : Integer := A'First (1);
> begin
>     return B : Complex_Matrix (1..A'Length (1)-1, 1..A'Length (2)-1) do
>        AI := A'First (1);
>        for BI in B'Range (1) loop
>           if AI = I then
>              AI := AI + 1;
>           end if;
>           AJ := A'First (2);
>           for BJ in B'Range (2) loop
>              if AJ = J then
>                 AJ := AJ + 1;
>              end if;
>              B (BI, BJ) := A (AI, AJ);
>              AJ := AJ + 1;
>           end loop;
>           AI := AI + 1;
>        end loop;
>     end return;
> end Exclude;
>

Thanks again for the function. If I use it in my engineering
HOWTO cheat sheet, will put your name as the credit on it.

regards,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Sun, 24 Jun 2012 12:14:11 -0500, Nasser M. Abbasi wrote:

> I think Ada should add more
> support for more build-in type functions for matrix/vector operations.
> 
> At least, 2D slicing of arrays should be possible?

Yes, but the reason why nD slices are is not included is likely for
efficiency reasons. Anyway, slices would not help. Excluding rows and
columns is another sort of operations.

I don't think the language should provide slices. It should provide means
to define operations using slice syntax instead.

> If not, that
> mask/pack functionality as in Fortran, should be present in Ada
> as part of the library.

No, that is low-level mess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[J-P. Rosen]

Le 24/06/2012 19:14, Nasser M. Abbasi a �crit :

If you want to avoid "if" in "loop":

>> If you want a function which would return a submatrix obtained by
>> removing
>> the row I and column J:
> 
 function Exclude (A : Complex_Matrix; I, J : Integer)
     return Complex_Matrix is
     AI, AJ : Integer := A'First (1);
 begin
     return B : Complex_Matrix (1..A'Length (1)-1, 1..A'Length (2)-1) do
        BI := 1;
        for AI in A'First (1) .. I-1 loop
           BJ := 1;
           for AJ in A'First (2) .. J-1 loop
              B (BI, BJ) := A (AI, AJ);
              BJ := BJ + 1;
           end loop;

           for AJ in J+1 .. A'Last (2) loop
              B (BI, BJ) := A (AI, AJ);
              BJ := BJ + 1;
           end loop;
           BI := BI + 1;
        end loop;

        for AI in I+1 .. A'Last (1) loop
           BJ := 1;
           for AJ in A'First (2) .. J-1 loop
              B (BI, BJ) := A (AI, AJ);
              BJ := BJ + 1;
           end loop;

           for AJ in J+1 .. A'Last (2) loop
              B (BI, BJ) := A (AI, AJ);
              BJ := BJ + 1;
           end loop;
           BI := BI + 1;
        end loop;
     end return;
 end Exclude;


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 12:44 AM, J-P. Rosen wrote:
> Le 24/06/2012 19:14, Nasser M. Abbasi a �crit :
>
> If you want to avoid "if" in "loop":
>
>>> If you want a function which would return a submatrix obtained by
>>> removing
>>> the row I and column J:
>>
>   function Exclude (A : Complex_Matrix; I, J : Integer)
>       return Complex_Matrix is
>       AI, AJ : Integer := A'First (1);
>   begin
>       return B : Complex_Matrix (1..A'Length (1)-1, 1..A'Length (2)-1) do
>          BI := 1;
>          for AI in A'First (1) .. I-1 loop
>             BJ := 1;
>             for AJ in A'First (2) .. J-1 loop
>                B (BI, BJ) := A (AI, AJ);
>                BJ := BJ + 1;
>             end loop;
>
>             for AJ in J+1 .. A'Last (2) loop
>                B (BI, BJ) := A (AI, AJ);
>                BJ := BJ + 1;
>             end loop;
>             BI := BI + 1;
>          end loop;
>
>          for AI in I+1 .. A'Last (1) loop
>             BJ := 1;
>             for AJ in A'First (2) .. J-1 loop
>                B (BI, BJ) := A (AI, AJ);
>                BJ := BJ + 1;
>             end loop;
>
>             for AJ in J+1 .. A'Last (2) loop
>                B (BI, BJ) := A (AI, AJ);
>                BJ := BJ + 1;
>             end loop;
>             BI := BI + 1;
>          end loop;
>       end return;
>   end Exclude;
>
>


Thanks J-P. Rosen.

Ada is nice as it strongly typed and catches common errors. But
it is not as 'expressive' I am afraid as I'd like for this
sort of thing.

In Mathematica for example, I do this whole operation in one line:

---------------------------
Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
---------------------------

That is all. This generates all submatrices from A as needed
in this problem :)

I've been learning Mathematica, and I find functional programming
really powerful vs imperative programming, but it needs much more
time getting used to.

But this is for another topic and place to discuss.

Thanks again for your input!

--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[J-P. Rosen]

Le 25/06/2012 08:32, Nasser M. Abbasi a �crit :
> Ada is nice as it strongly typed and catches common errors. But
> it is not as 'expressive' I am afraid as I'd like for this
> sort of thing.
> 
> In Mathematica for example, I do this whole operation in one line:
> 
> ---------------------------
> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
> ---------------------------
> 
> That is all. This generates all submatrices from A as needed
> in this problem :)
> 
> I've been learning Mathematica, and I find functional programming
> really powerful vs imperative programming, but it needs much more
> time getting used to.

Right. Now talk about readability... Ada is for long-lived programs, and
places readability over writability. There is also a need for Kleenex
programs, where conciseness is a quality (APL is an extreme example).

Different needs, different solutions.


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Mon, 25 Jun 2012 09:54:49 +0200, J-P. Rosen wrote:

> Le 25/06/2012 08:32, Nasser M. Abbasi a �crit :

>> I've been learning Mathematica, and I find functional programming
>> really powerful vs imperative programming, but it needs much more
>> time getting used to.
> 
> Right. Now talk about readability... Ada is for long-lived programs, and
> places readability over writability.

There is an old idea that resource consuming constructs should look
syntactically heavier than more efficient ones (when at same abstraction
level). Declarative languages frequently (always?) defeat this principle,
which results in poor coding practice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Georg Bauhaus]

On 25.06.12 08:32, Nasser M. Abbasi wrote:
>
> In Mathematica for example, I do this whole operation in one line:
>
> ---------------------------
> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
> ---------------------------
>
> That is all. This generates all submatrices from A as needed
> in this problem :)

What if, as is usually the case, you'd have "primitive" array routines
like Pick, Take, Drop, Transpose, and then (this is what it looks
like here) implement the removals at i, j like like this:

    Shrunk := Transpose (Drop (i, Transpose (Drop (j, Matrix))));

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

>  function Exclude (A : Complex_Matrix; I, J : Integer)
>      return Complex_Matrix is
>      AI, AJ : Integer := A'First (1);
>  begin

I think AJ should be initialised to A'First (2).

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 3:36 AM, Georg Bauhaus wrote:
> On 25.06.12 08:32, Nasser M. Abbasi wrote:
>>
>> In Mathematica for example, I do this whole operation in one line:
>>
>> ---------------------------
>> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
>> ---------------------------
>>
>> That is all. This generates all submatrices from A as needed
>> in this problem :)
>

> What if, as is usually the case, you'd have "primitive" array routines
> like Pick, Take, Drop, Transpose, and then (this is what it looks
> like here) implement the removals at i, j like like this:
>
>      Shrunk := Transpose (Drop (i, Transpose (Drop (j, Matrix))));
>

Yes, that would help. Transpose is there already in Ada. (good).
Drop? I did not find this. googled for it. I assume this is just
an example then.

Actually, I do not think it is too hard to write functions similar
to Fortran's pack() and reshape(). The API for these is well defined
and these can be implemented in Ada as generic packages. These would
provide better solution, as they are general and will work for many
different cases, not just the one I had asked about here. Then there
will no need for Drop() as it would not be orthogonal to
Pack+reshape in terms of functionality, and those do what Drop
does and more.

When I get better in Ada, will try to do that myself :) I
just think functions like these, if they are part of the library,
would be better for everyone, so that not every programmer will
need to reinvent the wheel. (I wish Ada would be more interested
in scientific computation, as I think it has the potential to
be really good in that area due to its strong typing) but I think
Ada is more interested in system programming.

thanks,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 2:54 AM, J-P. Rosen wrote:
> Le 25/06/2012 08:32, Nasser M. Abbasi a �crit :
>> Ada is nice as it strongly typed and catches common errors. But
>> it is not as 'expressive' I am afraid as I'd like for this
>> sort of thing.
>>
>> In Mathematica for example, I do this whole operation in one line:
>>
>> ---------------------------
>> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
>> ---------------------------
>>
>> That is all. This generates all submatrices from A as needed
>> in this problem :)


> Right. Now talk about readability... Ada is for long-lived programs, and
> places readability over writability.

Sure. I agree with readability. But do you really think a 40
or 50 lines lines function will be more readable and easier to
understand and maintain than a 1 or 2 lines function?

For me, the above Mathematica one line code is much more readable, and
easier to understand. It uses patterns, yes, but _once_ one understands
the syntax, and how to use patterns, it all becomes so clear, and logical,
and actually easier to maintain and comprehend than a large function
that does the same thing.

btw, I am not even that good in Mathematica. Still learning it. There
are Mathematica experts who would probably write the above in 1/2 the size :)

regards,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Pascal Obry]

Le 25/06/2012 08:32, Nasser M. Abbasi a �crit :
> In Mathematica for example, I do this whole operation in one line:
> 
> ---------------------------
> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
> ---------------------------

Which is just unreadable if you ask me...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 11:49 AM, Pascal Obry wrote:
> Le 25/06/2012 08:32, Nasser M. Abbasi a �crit :
>> In Mathematica for example, I do this whole operation in one line:
>>
>> ---------------------------
>> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
>> ---------------------------
>
> Which is just unreadable if you ask me...
>
> Pascal.
>

Well, it is just because you are not used to the syntax. I am sure.

Just like when I read Perl, I do not understand it at all, but
I am sure someone who knows Perl, they would be able to write
in few words or lines some code to parse some strings, in what would
take me pages to write.

Once one gets used to the syntax and using pattern matching and
functional programming, it will become easy to read and understand,
and one will probably find it hard to go back to writing long
imperative code to do what they can do in few lines of functional
code.

Here is another one: Given a square matrix, determine if the
matrix is diagonal or not.

The function will return true if matirx is diagonal, and
false otherwise.

A diagonal matrix is one which have zeros everywhere off
the diagonal.

In Mathematica, this one line function does it

diagQ[m_] := m === DiagonalMatrix[Diagonal[m]]

Hence, given a matrix such as

a={{1,0,0},
    {0,2,0},
    {0,0,0}}

diagQ[a]
     ----> True

All what it does, is build up a diagonal matrix using the diagonal
elements of the matrix, and checks if the result is identical to
the matrix itself.

If I have to do this in Ada (unless there is build in function
to do this), I might have to use loops and check each element
off the diagonal, exist loop once I find non-zero element off
the diagonal, etc... and end up writing 20 lines of code at
least. (also I might have to make a contract pre/post may be,
not sure, may be not).

And I am not sure that will be more readable or easier to maintain
at the end.

ps. the above function does not have checks on its arguments, but
I can add these easily to make it more robust (using MatrixQ check
for example, and a check for matrix being square matrix, all easy/short
code to do).

regards,
--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[stefan-lucks]

On Mon, 25 Jun 2012, Nasser M. Abbasi wrote:

> Here is another one: Given a square matrix, determine if the
> matrix is diagonal or not.

This is an easy challenge.

Ada 2012 provides a reasonably simple way to do this:

1. Specify the type of the Matrix, e.g.,

     type Matrix is array (Positive range <>, Positive range <>) of Float;

2. Specify the precondition (optional):

     function Is_Diagonal (M: Matrix) return Boolean
       with Pre => M'First(1) = M'First(2) and M'Last(1) = M'Last(2);

3. Implement the function:

     function Is_Diagonal (M: Matrix) return Boolean is
        (for all I in M'Range(1)
           => (for all J in M'Range(2)
                 => (if I /= J then M(I, J) = 0.0)));

This is four lines -- but the last two or three lines could be squeezed 
into a single one, if all what matters is the line count, disregarding 
readability. 

> In Mathematica, this one line function does it
> 
> diagQ[m_] := m === DiagonalMatrix[Diagonal[m]]

The comparison with Mathematica is a bit unfair. It uses some auxiliary 
functions that are just there in Mathematica, and could be easily be 
implemented in Ada as well. 

And your estimate of 20 lines is excessive. Consider the following 
specifications:

      type Matrix is array(Positive range <>, Positive range <>) of Float;
      type Vector is array(Positive range <>) of Float;

      function Is_Diagonal (M: Matrix) return Boolean
         with Pre => M'First(1) = M'First(2) and M'Last(1) = M'Last(2);

      function Diagonal (M: Matrix) return Vector
         with Pre => M'First(1) = M'First(2) and M'Last(1) = M'Last(2);

      function Diagonal_Matrix(V: Vector) return Matrix;

Implementing all three functions in Ada takes just 19 lines (not counting 
the empty ones):

      function Diagonal(M: Matrix) return Vector is
         V: Vector(M'First(1) .. M'Last(1));
      begin
         for I in V'Range loop
            V(I) := M(I, I);
         end loop;
         return V;
      end Diagonal;

      function Diagonal_Matrix(V: Vector) return Matrix is
         M: Matrix(V'First .. V'Last, V'First .. V'Last)
           := (others => (others => 0.0));
      begin
         for I in V'Range loop
            M(I, I) := V(I);
         end loop;
         return M;
      end Diagonal_Matrix;

      function Is_Diagonal (M: Matrix) return Boolean is
         (M  = Diagonal_Matrix(Diagonal(M)));



-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Jerry]

Most submatrix needs, including Nasser's example, can be handled by
slices (or slice syntax--not sure what the difference is). Boolean
masks would not often be needed.

Why doesn't Ada provide this? It seems that one of the Ada design
principles has been to build in commonly used features rather than
force the user to write them, setting up the greater possibility of
mistakes and inefficiencies. Slices exist for 1D arrays; why not for
>1D arrays?

The reverse operation, composition, is also useful. In Matlab/Octave
(assuming compatible sizes):
C = [A, B] makes A B
and
D = [A; B] makes
  A
  B
and
[0, 0, 0, A; B, 0, 0, 0] makes
   0   0   0   A
   B   0   0   0
etc.

Which brings me to one of my least favorite Ada features, the use of
() instead of [] for array indices. Talk about a readability killer.
But I'm sure that's been beat to death many times. (No, it's not
because [] are not part of ASCII.)

Jerry

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 9:48 PM, Jerry wrote:
>
> The reverse operation, composition, is also useful. In Matlab/Octave
> (assuming compatible sizes):
> C = [A, B] makes A B
> and
> D = [A; B] makes
>    A
>    B
> and
> [0, 0, 0, A; B, 0, 0, 0] makes
>     0   0   0   A
>     B   0   0   0
> etc.
>

If you are interested in comparing specifically matrix/vector
operations, I have a specific note in my HOWTO cheat sheet
just for this topic, it is at node 66:

http://12000.org/my_notes/mma_matlab_control/KERNEL/node66.htm

side-by-side comparison. I have Matlab, Mathematica, and
started to add Fortran. Might add Ada later on, but I am
not good in Ada to do that yet. I am not even good in Fortran
but I added few examples just to compare the ease).

Matlab and Mathematica do make working with matrices
and vectors very easy. Since the syntax and functions that are
build into them makes it so. They are designed for this
type of work. In Mathematica one uses patterns and many build-in
functions to do that, while in Matlab it is mostly the nice
build-in syntax designed for matrix work.

> Which brings me to one of my least favorite Ada features, the use of
> () instead of [] for array indices. Talk about a readability killer.

Yes. I would have preferred [] for arrays. But this was talked
about before many times. The view is that array access can be
looked at mathematically as also a function call.

When one writes A(3), then this is also a function call that
takes 3 as its argument and returns the value at that location.

But I myself would prefer [] for indexing and () for 'actual'
function call, just so that when I am reading code, [] will
remind me I am looking at an array not a function.

But too late for Ada to do this change. Already baked in. It
is interesting that in Pascal one uses [] for arrays and Ada
was based on Pascal. But the original designers for Ada for
some reason did not follow Pascal here. too bad.

> But I'm sure that's been beat to death many times. (No, it's not
> because [] are not part of ASCII.)
>
> Jerry
>

--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 1:49 PM, stefan-lucks@see-the.signature wrote:

> 2. Specify the precondition (optional):
>
>       function Is_Diagonal (M: Matrix) return Boolean
>         with Pre => M'First(1) = M'First(2) and M'Last(1) = M'Last(2);
>
> 3. Implement the function:
>
>       function Is_Diagonal (M: Matrix) return Boolean is
>          (for all I in M'Range(1)
>             => (for all J in M'Range(2)
>                   => (if I /= J then M(I, J) = 0.0)));
>
> This is four lines -- but the last two or three lines could be squeezed
> into a single one, if all what matters is the line count, disregarding
> readability.

That is a very nice solution. Thanks. I'll have to wait for gnat
2012 to try it. (I assume the pre above is checking for square matrix,
ps. the new iterator looks nice).

--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/25/2012 9:48 PM, Jerry wrote:

>
> Which brings me to one of my least favorite Ada features, the use of
> () instead of [] for array indices.

fyi,
I found the allowed characters in Ada in the original
steelman document, dated June 1978

http://archive.adaic.com/docs/reports/steelman/steelman.htm#2

"Every source program shall also have a representation that
uses only the following 55 character subset of the ASCII graphics:

     %&'()*+,-./:;<=>?
    0123456789
    ABCDEFGHIJKLMNOPQRSTUVWXYZ_

"

You see that [] were not even in the allowed character set.

--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Mon, 25 Jun 2012 19:48:48 -0700 (PDT), Jerry wrote:

> Which brings me to one of my least favorite Ada features, the use of
> () instead of [] for array indices.

[x] means fraction, or else [a,b] does closed interval, or else does
literal matrix. I never saw [] used for indices in literature.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Jacob Sparre Andersen]

Nasser M. Abbasi wrote:
> J-P. Rosen wrote:

>>   function Exclude (A : Complex_Matrix; I, J : Integer)
>>       return Complex_Matrix is
>>       AI, AJ : Integer := A'First (1);

I suspect a compiler would advise that the above line is changed to:

         BI, BJ : Integer;

>>   begin
>>       return B : Complex_Matrix (1..A'Length (1)-1, 1..A'Length (2)-1) do
>>          BI := 1;
>>          for AI in A'First (1) .. I-1 loop
>>             BJ := 1;
>>             for AJ in A'First (2) .. J-1 loop
>>                B (BI, BJ) := A (AI, AJ);
>>                BJ := BJ + 1;
>>             end loop;
>>
>>             for AJ in J+1 .. A'Last (2) loop
>>                B (BI, BJ) := A (AI, AJ);
>>                BJ := BJ + 1;
>>             end loop;
>>             BI := BI + 1;
>>          end loop;
>>
>>          for AI in I+1 .. A'Last (1) loop
>>             BJ := 1;
>>             for AJ in A'First (2) .. J-1 loop
>>                B (BI, BJ) := A (AI, AJ);
>>                BJ := BJ + 1;
>>             end loop;
>>
>>             for AJ in J+1 .. A'Last (2) loop
>>                B (BI, BJ) := A (AI, AJ);
>>                BJ := BJ + 1;
>>             end loop;
>>             BI := BI + 1;
>>          end loop;
>>       end return;
>>   end Exclude;

> In Mathematica for example, I do this whole operation in one line:
>
> ---------------------------
> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
> ---------------------------

I'm not sure if Mathematica has sufficient syntax highlighting to make
it easy to keep track of the grouping of the various parentheses, but as
it appears here, I would definitely want to break it up a bit, to make
it more readable. - My Mathematica so rusty that even when I do that,
I'm still not quite certain that your function works correctly.

Yes, the Ada solution Jean-Pierre presented is more verbose.  (And yes,
there was an error in it. ;-)

But to an Ada programmer with a bit of experience, the challenging part
is to make sure the indexes aren't mixed up anywhere.  This takes some
time. - But (to me) counting parenteses and making sure they match up
also takes time.  (But probably not quite as much.)

Greetings,

Jacob
-- 
"It ain't rocket science!"

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Nasser M. Abbasi]

On 6/26/2012 2:15 AM, Jacob Sparre Andersen wrote:

>> ---------------------------
>> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
>> ---------------------------
>
> I'm not sure if Mathematica has sufficient syntax highlighting to make
> it easy to keep track of the grouping of the various parentheses,

Yes it does, when using the notebook interface, using menus
one can tell it to find matching [] (I'll go crazy without this feature)

> but as it appears here,  I would definitely want to break it up a bit, to make
> it more readable.

But it is allready very readable !  ;)

> - My Mathematica so rusty that even when I do that,
> I'm still not quite certain that your function works correctly.
>

Sure it works. Please see  http://alturl.com/jh4pj

>
> Greetings,
>
> Jacob
>

--Nasser

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Georg Bauhaus]

On 25.06.12 15:17, Nasser M. Abbasi wrote:
> On 6/25/2012 3:36 AM, Georg Bauhaus wrote:
>> On 25.06.12 08:32, Nasser M. Abbasi wrote:
>>>
>>> In Mathematica for example, I do this whole operation in one line:
>>>
>>> ---------------------------
>>> Table[ReplacePart[A,{{i},{i,_},{_,j}}:>Sequence[]],{i,nRow},{j,nCol}];
>>> ---------------------------
>>>
>>> That is all. This generates all submatrices from A as needed
>>> in this problem :)
>>
> 
>> What if, as is usually the case, you'd have "primitive" array routines
>> like Pick, Take, Drop, Transpose, and then (this is what it looks
>> like here) implement the removals at i, j like like this:
>>
>>      Shrunk := Transpose (Drop (i, Transpose (Drop (j, Matrix))));
>>
> 
> Yes, that would help. Transpose is there already in Ada. (good).
> Drop? I did not find this. googled for it. I assume this is just
> an example then.

It is fairly easy to write, indeed. Nevertheless, I believe that
such operations should be a little higher level than Fortran's pack.
The latter seems good for implementing the operations, provided
the language allows (re-)attaching dimensions to a lump of data.
I am not sure that Ada's index type based array indexing
is the best model for such flexibility at all levels.
It certainly does not seem strictly necessary to implement some
"primitive" operations.

Nevertheless, Iverson's A Programming Language, and more specifically,
introductory work based on it (things that I can hope to understand in finite
time :), and language work based on it (APL, J, possibly S and R),
reveal a good set of "primitive" operations on arrays, functional style.
Some of these are in Ada already, for example, array concatenation "&",
and (some) indexing. Some can be built using a container/iterator
approach, I think, for example, applying a function to all elements,
either updating the array, or producing a new one. There are simpler
ways to do that, though, even in Ada 83, but they may be a little
less flexible for STL style algorithm work. Just a guess.

Array operations are again interesting for automatic parallelism in
the small, now that consumer hardware has a small array of vector
hardware.

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Robert A Duff]

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

> http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
>
> "Every source program shall also have a representation that
> uses only the following 55 character subset of the ASCII graphics:
>
>     %&'()*+,-./:;<=>?
>    0123456789
>    ABCDEFGHIJKLMNOPQRSTUVWXYZ_
>
> "
>
> You see that [] were not even in the allowed character set.

And yet string literals used double quotes, aggregates use
vertical bar, and based literals use sharp sign, even
though I don't see any of:

    " | #

listed above.  [] were not outlawed by the above requirement,
either.

- Bob

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Adam Beneschan]

On Monday, June 25, 2012 7:48:48 PM UTC-7, Jerry wrote:
> Most submatrix needs, including Nasser's example, can be handled by
> slices (or slice syntax--not sure what the difference is). Boolean
> masks would not often be needed.
> 
> Why doesn't Ada provide this? It seems that one of the Ada design
> principles has been to build in commonly used features rather than
> force the user to write them, setting up the greater possibility of
> mistakes and inefficiencies. Slices exist for 1D arrays; why not for
> >1D arrays?

I think one of the main reasons is that you couldn't do everything with a 2-D slice that you could do with a 1-D slice.  In particular, parameter passing would be an issue.  If you declare a procedure

  type Some_Array is array (natural range <>) of Something; 
  procedure Proc (A : in out Some_Array);

you can pass a slice of some other array

  Proc (B (7 .. 23));

and the since the elements of the slice are all still contiguous, Proc could treat the parameter the same as it would any other array--it wouldn't have to know whether the actual parameter was an entire array or a slice.  That wouldn't be the case with 2-D slices.  Some additional logic in Proc would be needed to deal with non-contiguous slices, and that additional logic would have to be there in Proc whether or not a 2-D slice was actually passed to it anywhere.

I realize that this may not be important to all programmers, and that they'd rather have the ability to express what they want and not worry about whether it slows things down ("distributed overhead").  But I think that being able to generate efficient code was one of the design principles in Ada 83.

                               -- Adam

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Adam Beneschan]

On Tuesday, June 26, 2012 5:54:00 AM UTC-7, Robert A Duff wrote:
> 
> > http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
> >
> > "Every source program shall also have a representation that
> > uses only the following 55 character subset of the ASCII graphics:
> >
> >     %&'()*+,-./:;<=>?
> >    0123456789
> >    ABCDEFGHIJKLMNOPQRSTUVWXYZ_
> >
> > "
> >
> > You see that [] were not even in the allowed character set.
> 
> And yet string literals used double quotes, aggregates use
> vertical bar, and based literals use sharp sign, even
> though I don't see any of:
> 
>     " | #
> 
> listed above.  [] were not outlawed by the above requirement,
> either.

In Ada 83, those three characters could be replaced by %, !, : respectively.  (It's still in the language as a deprecated feature; see J.2.)

I don't think it would have worked to say that [] is used for array indexing, but that they could be replaced by () if the symbols [] weren't available.  The reason was is that changing [] to () would introduce some ambiguities where none existed before, which I think would really screw up the overload resolution rules.  (Suppose you have two functions F, one that takes an integer parameter and returns an integer, and one that takes no parameters and returns a array of integer or an access to an array of integer.  Now, if [] were used as the array index, with no replacement allowed?  F(3) would unambiguously call the F that takes a parameter and F[3] would unambiguously call the parameterless F that returns an array or access-array.  But what if the rules said that [ and ] could be relaced by ( and )?  What would the rules say about F(3) now?  I think this would be too confusing.)  Another possibility would be to say that [ and ] could be replaced by two-character sequences such as, for instance, (: and :)   This would be unambiguous because smileys hadn't yet been invented.  I think that would have worked but I guess nobody thought of that.

                                  -- Adam
 

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> In Ada 83, those three characters could be replaced by %, !, :
> respectively.  (It's still in the language as a deprecated feature;
> see J.2.)
>
> I don't think it would have worked to say that [] is used for array
> indexing, but that they could be replaced by () if the symbols []
> weren't available.  The reason was is that changing [] to () would
> introduce some ambiguities where none existed before, which I think
> would really screw up the overload resolution rules.  (Suppose you
> have two functions F, one that takes an integer parameter and returns
> an integer, and one that takes no parameters and returns a array of
> integer or an access to an array of integer.  Now, if [] were used as
> the array index, with no replacement allowed?  F(3) would
> unambiguously call the F that takes a parameter and F[3] would
> unambiguously call the parameterless F that returns an array or
> access-array.  But what if the rules said that [ and ] could be
> relaced by ( and )?  What would the rules say about F(3) now?

You could make that work.  The rules would say that F(3) and F[3]
are ambiguous, given the two F's you mention above.  Then a legality
rule would say you have to use [] for arrays.

But that's not what I was thinking of.

>...I think
> this would be too confusing.)

Agreed.  And it doesn't really accomplish the goal, because
when you see A(I) you don't know if it's a call or an array indexing.
Apparently, Ichbiah et al didn't share that goal anyway -- they
thought it's a feature to confuse calls and array indexing.
I have mixed feelings about it.  On the one hand, a constant
array is just like a function without side effects.  But on the
other hand, when you consider that you can do "A(I) := ..."
for arrays, and function calls can go around modifying global
variables, the two features don't look very similar.
All in all, I'm in favor of two different notations.

>...Another possibility would be to say
> that [ and ] could be replaced by two-character sequences such as, for
> instance, (: and :) This would be unambiguous because smileys hadn't
> yet been invented.

Yeah, THAT's what I was thinking of.  Or (. and .) .

>...I think that would have worked but I guess nobody
> thought of that.

Well, they should have.  After all, they came up with essentially
the same idea for " | #.  And they supposedly started their
design based on Pascal, which uses the same idea -- comments
are surrounded by {...}, but you're allowed to use (*...*)
instead.  This isn't rocket science!  ;-)

Using the same syntax for arrays and functions doesn't bother
me THAT much, but it really rubs me the wrong way that you
can't have zero- and one-component positional aggregates.
Using [...] for aggregates would solve that, without
ambiguity.  And blaming that large language design flaw
on character set / keyboard issues doesn't hold water.

The steelman requirement that somebody quoted was:

    "Every source program shall also have a representation that
    uses only the following 55 character subset of the ASCII graphics:

Note "also have", which can be accomplished by these optional
replacements.

By they way, they didn't actually meet that requirement.
Can you think of an Ada 83 program that cannot be represented
in those 55 characters?  ;-)

- Bob

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> you can pass a slice of some other array
>
>   Proc (B (7 .. 23));
>
> and the since the elements of the slice are all still contiguous, Proc
> could treat the parameter the same as it would any other array--it
> wouldn't have to know whether the actual parameter was an entire array
> or a slice.  That wouldn't be the case with 2-D slices.  Some
> additional logic in Proc would be needed to deal with non-contiguous
> slices, and that additional logic would have to be there in Proc
> whether or not a 2-D slice was actually passed to it anywhere.
>
> I realize that this may not be important to all programmers, and that
> they'd rather have the ability to express what they want and not worry
> about whether it slows things down ("distributed overhead").  But I
> think that being able to generate efficient code was one of the design
> principles in Ada 83.

Well, efficient code (or more precisely, avoiding distributed overhead)
was a design goal of Fortran, too, yet Fortran has multi-dim slices.
You have to pass in the "stride" (distance between noncontiguous
pieces).

Also if the goal was to avoid distributed overhead, why on earth do we
have to store millions of copies of the number 1 (the 'First value for
almost all Strings)?  A complete waste of memory, and also a rich
source of bugs.

- Bob

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Adam Beneschan]

On Tuesday, June 26, 2012 2:19:36 PM UTC-7, Robert A Duff wrote:

> > I realize that this may not be important to all programmers, and that
> > they'd rather have the ability to express what they want and not worry
> > about whether it slows things down ("distributed overhead").  But I
> > think that being able to generate efficient code was one of the design
> > principles in Ada 83.
> 
> Well, efficient code (or more precisely, avoiding distributed overhead)
> was a design goal of Fortran, too, yet Fortran has multi-dim slices.
> You have to pass in the "stride" (distance between noncontiguous
> pieces).

True.  That's a pretty small amount of overhead.

Really, I was just making an educated guess as to why they allowed 1-dimensional slices but not higher dimensions.  I don't have the real answer, unless I happened to guess right.  Does anyone else know more about this?

                          -- Adam

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Shark8]

On Tuesday, June 26, 2012 2:06:01 AM UTC-5, Nasser M. Abbasi wrote:
> On 6/25/2012 9:48 PM, Jerry wrote:
> 
> >
> > Which brings me to one of my least favorite Ada features, the use of
> > () instead of [] for array indices.
> 
> fyi,
> I found the allowed characters in Ada in the original
> steelman document, dated June 1978
> 
> http://archive.adaic.com/docs/reports/steelman/steelman.htm#2
> 
> "Every source program shall also have a representation that
> uses only the following 55 character subset of the ASCII graphics:
> 
>      %&'()*+,-./:;<=>?
>     0123456789
>     ABCDEFGHIJKLMNOPQRSTUVWXYZ_
> 
> "
> 
> You see that [] were not even in the allowed character set.
> 
> --Nasser

I also notice there's no double-quote.

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:3f8db781-fd78-4505-837d-1811c0f9b96f@googlegroups.com...
> On Tuesday, June 26, 2012 2:19:36 PM UTC-7, Robert A Duff wrote:
>
>> > I realize that this may not be important to all programmers, and that
>> > they'd rather have the ability to express what they want and not worry
>> > about whether it slows things down ("distributed overhead").  But I
>> > think that being able to generate efficient code was one of the design
>> > principles in Ada 83.
>>
>> Well, efficient code (or more precisely, avoiding distributed overhead)
>> was a design goal of Fortran, too, yet Fortran has multi-dim slices.
>> You have to pass in the "stride" (distance between noncontiguous
>> pieces).
>
> True.  That's a pretty small amount of overhead.

Huh? A stride isn't enough for a general slice. I suppose you are thinking 
that a slice has to be a 1D array, but that doesn't follow IMHO. I always 
thought that a 2D slice should be 2D (at least possible to have that). And 
if you have something like M (2 .. 3, 2 .. 4), this is does not have fixed 
strides between the included elements. Even if you assume a slice is 1D, you 
have to support selecting parts of rows, and the syntax would have two 
dimensions.

All which means that the result would be too complex to use for most people. 
Not to mention the extra overhead. (I agree that the overhead would not be 
too bad for unconstrained array parameters, which are passing a descriptor 
anyway; but for constrained array parameters, which don't pass any 
descriptors, this would require a substantial change in the way array 
parameters are passed and managed (adding a lot of overhead to the uses of 
those arrays).)

> Really, I was just making an educated guess as to why they allowed 
> 1-dimensional slices
> but not higher dimensions.  I don't have the real answer, unless I 
> happened to guess right.
> Does anyone else know more about this?

Not really; I've always assumed like you did (and as above). The Ada 83 
Rationale doesn't say anything about this in the section on slices, so it 
may be lost to the mists of time.

                                 Randy.

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Mon, 2 Jul 2012 23:22:46 -0500, Randy Brukardt wrote:

> All which means that the result would be too complex to use for most people.

Too complex compared to writing it manually?
 
> Not to mention the extra overhead.

Again, compared to what?

Slices should be first class, that would remove the burden of
implementation from compiler writers. The rest is just same problematic as
with referencing single array/container element. There is no big difference
for one element or a set of elements.

The language should support that for all container types, array is one. Ada
2012 has a kludge for doing that by reference. There should be another for
doing that using value semantics (copy-out, copy-in).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:18bqgllh2jdwg$.upj6crleq9nv$.dlg@40tude.net...
> On Mon, 2 Jul 2012 23:22:46 -0500, Randy Brukardt wrote:
>
>> All which means that the result would be too complex to use for most 
>> people.
>
> Too complex compared to writing it manually?

Yes. If the meaning of the syntax is not immediately obvious, you run a 
significant risk of reading/writing something other than what you really 
want. I can think of at least two meanings for A(2..3, 4..4), and that is 
where the problem arises.

>> Not to mention the extra overhead.
>
> Again, compared to what?

Compared to a language without 2-d slices.

This is distributed overhead, which programs would  have to pay whether or 
not they used any 2-d slices. It would make all array parameters more 
expensive. Distributed overhead is only acceptable in cases where there is a 
clear and important value to the new feature.

The overhead for the slicing feature itself isn't a problem, it's the 
overhead for all of the programs that don't use the feature and don't care 
about the feature that is the problem.

> Slices should be first class, that would remove the burden of
> implementation from compiler writers. The rest is just same problematic as
> with referencing single array/container element. There is no big 
> difference
> for one element or a set of elements.

That's not really possible so long as slices are what C calls l-values. The 
problem is passing slices as parameters and allowing assignments into them. 
(Just allowing them to be read is not much of a problem, at least for 
by-copy types.)

> The language should support that for all container types, array is one. 
> Ada
> 2012 has a kludge for doing that by reference. There should be another for
> doing that using value semantics (copy-out, copy-in).

Value semantics only works for a small subset of types (for most compilers, 
that subset is elementary types). Moreover, Ada has many types for which 
value semantics is not allowed (immutably limited types and tagged types are 
the best known). So this would be a feature of fairly limited value.

I'd rather spend my time getting exception contracts to work.

                                    Randy.

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Wed, 4 Jul 2012 20:33:32 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:18bqgllh2jdwg$.upj6crleq9nv$.dlg@40tude.net...
>> On Mon, 2 Jul 2012 23:22:46 -0500, Randy Brukardt wrote:
>>
>>> All which means that the result would be too complex to use for most 
>>> people.
>>
>> Too complex compared to writing it manually?
> 
> Yes. If the meaning of the syntax is not immediately obvious, you run a 
> significant risk of reading/writing something other than what you really 
> want. I can think of at least two meanings for A(2..3, 4..4), and that is 
> where the problem arises.

It is unambiguous. 4..4 is a set of indices. 4 is an index. No difference
compared to A(4..4) vs. A(4), or, for that matter, "a" vs 'a'.

>>> Not to mention the extra overhead.
>>
>> Again, compared to what?
> 
> Compared to a language without 2-d slices.
> 
> This is distributed overhead, which programs would  have to pay whether or 
> not they used any 2-d slices. It would make all array parameters more 
> expensive.

By-value passed slices should impose no overhead.

>> Slices should be first class, that would remove the burden of
>> implementation from compiler writers. The rest is just same problematic as
>> with referencing single array/container element. There is no big 
>> difference for one element or a set of elements.
> 
> That's not really possible so long as slices are what C calls l-values. The 
> problem is passing slices as parameters and allowing assignments into them.

Why does this work for array elements then?

As for assignments in general, yes, there is a fundamental problem that the
user is not allowed to define them as a doubly dispatching operation. But
this is not specific to arrays. It is same for all containers.

>> The language should support that for all container types, array is one. Ada
>> 2012 has a kludge for doing that by reference. There should be another for
>> doing that using value semantics (copy-out, copy-in).
> 
> Value semantics only works for a small subset of types (for most compilers, 
> that subset is elementary types). Moreover, Ada has many types for which 
> value semantics is not allowed (immutably limited types and tagged types are 
> the best known). So this would be a feature of fairly limited value.

I don't see big problem here. Arrays of referential elements are most
likely internally are array of pointers. Slices of such arrays are again
arrays of pointers. There is nothing difficult about that, except that
usual problems that a reference shall not outlive the object. 

> I'd rather spend my time getting exception contracts to work.

Yes, exceptions (assignments, MD) are more important.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Adam Beneschan]

On Wednesday, July 4, 2012 6:33:32 PM UTC-7, Randy Brukardt wrote:

> > Again, compared to what?
> 
> Compared to a language without 2-d slices.
> 
> This is distributed overhead, which programs would  have to pay whether or 
> not they used any 2-d slices. It would make all array parameters more 
> expensive. Distributed overhead is only acceptable in cases where there is a 
> clear and important value to the new feature.

It seems to me that the "generalized indexing" syntax of Ada 2012 could be used to write a package to support this functionality.  I think you could write a generic package that defines a 2-D array of an element type, but defines it as a tagged record that (internally) points to the array storage.  The package would define First, Last, Length functions for the type that take a dimension parameter.  It could also define a Slice function that would return a new 2-D array with the new bounds, but pointing to the same storage.  The new syntax would allow programmers to index the array in the same way they would now.  Of course, not all the syntax would be equivalent, and some would require extra typing; you'd have to say something like

   for I in Arr.First(1) .. Arr.Last(1) loop

instead of

   for I in Arr'Range(1)

I haven't studied all the details.  But off the top of my head, I think this could be made to work, and probably could be implemented with only a slight amount of overhead compared to if it were built into the language.  Since 2-D slices aren't a feature I'd expect to be used widely, this seems like a better approach than adding it to the language and incurring distributed overhead (on top of all the other overhead required to change all existing Ada implementations without breaking them, and making changes to the standard).

                          -- Adam

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:3u95tkqb1l8t$.t7lzt049tvq8.dlg@40tude.net...
> On Wed, 4 Jul 2012 20:33:32 -0500, Randy Brukardt wrote:
...
>> This is distributed overhead, which programs would  have to pay whether 
>> or
>> not they used any 2-d slices. It would make all array parameters more
>> expensive.
>
> By-value passed slices should impose no overhead.

Sure. but they're not a general solution. That is, they don't work for 
slices of arrays of by-reference types, which a compiler would have to 
support. Since this is not an important feature for our customers, we would 
not want to support more than one implementation of it. And even if we did, 
there would still be distributed overhead in any parameter type that could 
not be passed by copy (which is most of them, if new types are always 
controlled, as I recommend in most cases).


>>> Slices should be first class, that would remove the burden of
>>> implementation from compiler writers. The rest is just same problematic 
>>> as
>>> with referencing single array/container element. There is no big
>>> difference for one element or a set of elements.
>>
>> That's not really possible so long as slices are what C calls l-values. 
>> The
>> problem is passing slices as parameters and allowing assignments into 
>> them.
>
> Why does this work for array elements then?

(There is a "not" missing in what I wrote above.)

It works for array elements only because they are contiguous and passing a 
single address is sufficient to represent the slice, as it is for any array 
objects. (Recall that we're talking about *constrained* array parameters 
here.)

...
...
>> Value semantics only works for a small subset of types (for most 
>> compilers,
>> that subset is elementary types). Moreover, Ada has many types for which
>> value semantics is not allowed (immutably limited types and tagged types 
>> are
>> the best known). So this would be a feature of fairly limited value.
>
> I don't see big problem here. Arrays of referential elements are most
> likely internally are array of pointers. Slices of such arrays are again
> arrays of pointers. There is nothing difficult about that, except that
> usual problems that a reference shall not outlive the object.

That's not how our compiler handles by-reference types. They live like other 
objects in place, but are always *passed* by reference (there is no 
requirement to *allocate* them by reference). There are some cases where we 
use implicit pointers (such as in shared generics), but that's unusual for 
Ada compilers. I don't think GNAT ever uses them.

                            Randy.

Re: Any easy/build-in construct to extract submatrices from larger matrix?

[Dmitry A. Kazakov]

On Fri, 6 Jul 2012 18:47:22 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:3u95tkqb1l8t$.t7lzt049tvq8.dlg@40tude.net...
>> On Wed, 4 Jul 2012 20:33:32 -0500, Randy Brukardt wrote:
> ...
>>> This is distributed overhead, which programs would  have to pay whether or
>>> not they used any 2-d slices. It would make all array parameters more
>>> expensive.
>>
>> By-value passed slices should impose no overhead.
> 
> Sure. but they're not a general solution.

I suppose it is for a great majority of people asking for this feature.
E.g. those doing linear algebra stuff.

> That is, they don't work for slices of arrays of by-reference types,

Yes, but nD arrays of those are rare. One important exception could be
arrays of controlled types used to implement fat pointers, e.g. handles.

>>>> Slices should be first class, that would remove the burden of
>>>> implementation from compiler writers. The rest is just same problematic as
>>>> with referencing single array/container element. There is no big
>>>> difference for one element or a set of elements.
>>>
>>> That's not really possible so long as slices are what C calls l-values. The
>>> problem is passing slices as parameters and allowing assignments into 
>>> them.
>>
>> Why does this work for array elements then?
> 
> (There is a "not" missing in what I wrote above.)
> 
> It works for array elements only because they are contiguous and passing a 
> single address is sufficient to represent the slice, as it is for any array 
> objects. (Recall that we're talking about *constrained* array parameters 
> here.)

That is why you could pass it copy-in/copy-out as you would with scalar
array elements. Yes, it would be much work and likely many compiler bugs,
but not impossible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de