Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

On 12/8/05, David Bateman <Dav...@mo...> wrote:
> It just does a cat along the last dimension of the cell array so that
> for example
>
> c =3D {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};
>
> becomes
>
> c1 =3D {[1, 2, 3, 4] ; [5 6 7 8; 9 10 11 12]}
>
> after the first interation. For 2-D there is only one iteration of the
> loop and the last cat operation is handled by "m =3D cat (1, c1{:})".
>

OK, thanks :)

> The fact is I'm not sure what you are trying to achieve with your
> changes. What was wrong with the previous implementation? cell2mat.m
> itself needs no argument dimension checking, as if the arguments are
> wrong, the dimension checking in the "cat" operation will cause an error
> and exit from cell2mat. For example with the current version of cell2mat
> I get the following, when passing it matrices that can't be concatenated.
>
> octave:2> C =3D {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
> octave:3> cell2mat(C)
> error: cat: dimension mismatch
> error: evaluating assignment expression near line 65, column 14
> error: evaluating for command near line 64, column 5
> error: evaluating for command near line 60, column 3
> error: called from `cell2mat' in file
> `/opt/octave-2.9/share/octave/2.9.4/site/m/octave-forge/cell/cell2mat.m'
>

Yes, but I wanted to make sure cell2mat.m checks for every restriction
specified in the Matlab documentation (same data type, can concatenate
into a hyperrectangle, matching dimensions for neighbouring cells).
Instead of letting cat print out the error, I think we should let
cell2mat do it. For example:

octave:21> C =3D {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
octave:22> cell2mat(C)
error: cell2mat: the contents of c must be able to concatenate into a
hyperrectangle
error: evaluating if command near line 75, column 13
error: evaluating if command near line 72, column 11
error: evaluating for command near line 69, column 9
error: evaluating if command near line 67, column 7
error: evaluating for command near line 66, column 5
error: evaluating if command near line 54, column 3
error: called from `cell2mat' in file `/home/william/cell2mat.m'

Admittedly the checking part is inefficient and ugly, so I'm asking
for some help here ;)

> Note that although
>
> C =3D {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
> cell2mat(C)
>

This one works in the old cell2mat, but not in the new cell2mat. Do
you think it should (work)? I mean, by the Matlab documentation, [1,
2] and [5; 9] are neighbours, but they differ in size (1x2 and 2x1,
while the neighbouring dimension is 1, thus while we ignore the first
dimension, we are comparing 2 to 1). How does Matlab behave?

> works, the generalization
>
> C =3D {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
> cell2mat(C)
>
> doesn't, even though conceptually the meaning is clear in terms of the
> hyper-rectangle. In general there must be a grid in the
> hyper-rectangular along which all matrices fill the elements of this
> grid. Matlab has the same behaviour.
>

I didn't realize the importance of the sentence "for each pair of
neighboring cells, the dimensions of the cells' contents must match,
excluding the dimension in which the cells are neighbors" until I read
your mail. I've added this item in the documentation (new file is
attached). Yes, your view of a "grid" is consistent with the Matlab
documentation.

By the way, I haven't implemented the "same data type" restriction.
Should cell2mat work that way? I mean, intuitively, concatenating
logical arrays with double arrays should at least work. How does
Matlab behave? Matlab's documentation itself says that c must have
contents of the same data type.

--
William Poetra Yoga Hadisoeseno