Charles Greathouse on Sun, 12 Feb 2012 19:38:19 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: matconcat


As much as it seems to differ from the usual philosophy, I would argue
for #1.  I think it's just too easy to give input that unintentionally
doesn't match, dimension-wise, and catching it is preferable to
continuing with probably-bad input.

I think failing on a dimension error is even more reasonable than
failing on, e.g., isprime(3.2) which seems less likely to lead to
error.

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Sun, Feb 12, 2012 at 11:09 AM, Karim Belabas
<Karim.Belabas@math.u-bordeaux1.fr> wrote:
> Hi pari-dev,
>
> I implemented a convenience GP function matconcat(v), which builds
> a (block) matrix from the components of v (see the examples below in P.S).
>
> For instance matconcat([A, B; C, D]) builds the matrix :
> [A | B]
> [-----]
> [C | D]
>
> The building blocks may be t_MAT, t_VEC [ row matrix ], t_COL [ column matrix ]
> and even scalars [ 1x1 matrix ]
>
> All this is straightforward when all dimensions match up, but I have a
> problem when they don't. What to do in this case ? I see at least 3
> possibilities:
>
> 1) reject and raise an exception.
>
> 2) consider a scalar 'x' as x * matid(proper dimension),
> e.g.
>  matconcat([3, matid(2); matid(2), 4])
>  %1 =
>  [3 0 1 0]
>
>  [0 3 0 1]
>
>  [1 0 4 0]
>
>  [0 1 0 4]
>
> 3) extend the blocks as needed, by rows and columns of 0
> e.g.
>  matconcat([3, matid(2); matid(2), 4])
>  %1 =
>  [3 0 1 0]
>
>  [0 0 0 1]
>
>  [1 0 4 0]
>
>  [0 1 0 0]
>
>
> 1) is simplest conceptually but somewhat contrary to the general PARI
> philosophy [ = try to make sense of all inputs, provided the specification
> can be documented in an elegant way ]
>
> 2) is already useful, but doesn't allow e.g.
>
>  matconcat(matdiagonal([[1,2;3,4], [1,2,3;4,5,6;7,8,9]]))
>
> [ = diagonal block matrix ]
>
> One can always add special cases, e.g. allow a "0" scalar, to represent an
> arbitrary rectangular block of zeroes, but it quickly becomes awkward.
>
> 3) is the current implementation, and e.g. returns
>  [1 2 0 0 0]
>
>  [3 4 0 0 0]
>
>  [0 0 1 2 3]
>
>  [0 0 4 5 6]
>
>  [0 0 7 8 9]
>
> on the above matdiagonal() input. It is very easy to describe and implement;
> unfortunately
>
> - we have to extend by zeroes in given directions [ currently to the right &
>  bottom ] without an easy way to extend otherwise,
>
> - this somewhat conlicts with how we currently treat scalars and square
>  matrices:
>  ? matid(2) - 3
>  %1 =
>  [-2  0]
>
>  [ 0 -2]
>
>  i.e. "3" is interpreted as 3 * Id_2, not as [3,0; 0,0].
>
>
> What do you think ?
>
>
> Cheers,
>
>    K.B.
>
> P.S.:
>
> (14:56) gp > ??matconcat
> matconcat(v):
>
>   Returns a t_MAT built from the entries of v, which may be a t_VEC
> (concatenate  horizontally),   a  t_COL   (concatenate vertically),  or a t_MAT
> (concatenate  vertically each column,  and concatenate vertically the resulting
> matrices).    The  entries  of  v  are  always considered as matrices: they can
> themselves be t_VEC (seen as a row matrix), a t_COL seen as a column matrix), a
> t_MAT, or a scalar (seen as an 1 x 1 matrix).
>
>   ? A=[1,2;3,4]; B=[5,6]~; C=[7,8]; D=9;
>   ? matconcat([A, B]) \\ horizontal
>   %1 =
>   [1 2 5]
>
>   [3 4 6]
>   ? matconcat([A, C]~) \\ vertical
>   %2 =
>   [1 2]
>
>   [3 4]
>
>   [7 8]
>   ? matconcat([A, B; C, D]) \\ block matrix
>   %3 =
>   [1 2 5]
>
>   [3 4 6]
>
>   [7 8 9]
>
>   If  the  dimensions of the entries to concatenate do not match up,  they are
> extended by 0 columns on the right and 0 rows at the bottom, as needed:
>
>   ? matconcat([1, [2,3]~, [4,5,6]~]) \\ horizontal
>   %4 =
>   [1 2 4]
>
>   [0 3 5]
>
>   [0 0 6]
>   ? matconcat([1, [2,3], [4,5,6]]~) \\ vertical
>   %5 =
>   [1 0 0]
>
>   [2 3 0]
>
>   [4 5 6]
>   ? matconcat([B, C; A, D]) \\ block matrix
>   %6 =
>   [5 0 7 8]
>
>   [6 0 0 0]
>
>   [1 2 9 0]
>
>   [3 4 0 0]
>
> --
> Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
> Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
> 351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~belabas/
> F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
> `
>