Menu
▾
▴
octave-dev
|
From: William P. Y. H. <wil...@gm...> - 2005-12-08 13:32:14
Attachments:
cell2mat.m
|
The blkdiag.m file I imported into Octave is dependent on cell2mat,
but I think it's not quite ready for inclusion into Octave yet. So I
modified the file (attached). Maybe the original author (Laurent
Mazet) and others would like to comment on it before I post it on
bu...@oc...?
Due to my lack of intelligence, I've so far failed to completely
understand the following code by Laurent (hey, but it works!) (it's
been reformatted):
for p =3D (ndims (c)):-1:2,
sz =3D size (c);
sz(end) =3D 1;
c1 =3D cell (sz);
for q =3D 1:(prod (sz))
c1{q} =3D cat (p, c{q:(prod (sz)):end});
endfor
c =3D c1;
endfor
m =3D cat (1, c1{:});
Can anyone explain it to me?
Note: I changed the wording of the license from "this program" to
"Octave". Is it OK?
--
William Poetra Yoga Hadisoeseno
|
|
From: David B. <Dav...@mo...> - 2005-12-08 14:41:59
|
William Poetra Yoga Hadisoeseno wrote:
>The blkdiag.m file I imported into Octave is dependent on cell2mat,
>but I think it's not quite ready for inclusion into Octave yet. So I
>modified the file (attached). Maybe the original author (Laurent
>Mazet) and others would like to comment on it before I post it on
>bu...@oc...?
>
>Due to my lack of intelligence, I've so far failed to completely
>understand the following code by Laurent (hey, but it works!) (it's
>been reformatted):
>
>for p = (ndims (c)):-1:2,
> sz = size (c);
> sz(end) = 1;
> c1 = cell (sz);
> for q = 1:(prod (sz))
> c1{q} = cat (p, c{q:(prod (sz)):end});
> endfor
> c = c1;
>endfor
>m = cat (1, c1{:});
>
>Can anyone explain it to me?
>
>Note: I changed the wording of the license from "this program" to
>"Octave". Is it OK?
>
>--
>William Poetra Yoga Hadisoeseno
>
>
>
It just does a cat along the last dimension of the cell array so that
for example
c = {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};
becomes
c1 = {[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 = cat (1, c1{:})".
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 = {[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'
Note that although
C = {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
cell2mat(C)
works, the generalization
C = {[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.
Regards
David
--
David Bateman Dav...@mo...
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
|
|
From: William P. Y. H. <wil...@gm...> - 2005-12-08 16:05:59
Attachments:
cell2mat.m
|
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
|
|
From: David B. <Dav...@mo...> - 2005-12-08 16:19:35
|
William Poetra Yoga Hadisoeseno wrote:
>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 = {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};
>>
>>becomes
>>
>>c1 = {[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 = 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 = {[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 = {[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 ;)
>
>
>
Again, why? Here is matlab's output
>> C = {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
>> cell2mat(C)
??? Error using ==> cat
CAT arguments dimensions are not consistent.
Error in ==> cell2mat at 92
m{n} = cat(2,c{n,:});
The error message seems to indicate that matlab just lets cat generate
the error as well.
>>Note that although
>>
>>C = {[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?
>
>
>
Matlab doesn't respect their own documentation either
>> C = {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
>> cell2mat(C)
ans =
1 2 3 4
5 6 7 8
9 10 11 12
This is with R14sp2..
>>works, the generalization
>>
>>C = {[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.
>
>
>
>> C = {[1;2],ones(2,2)==1}
C =
[2x1 double] [2x2 logical]
>> cell2mat(C)
??? Error using ==> cell2mat
All contents of the input cell array must be of the same data type.
However, this seems stupid to me, as logical arrays are supposed to be
promoted to double in normal usage... I'd prefer that the above remained
legal..
Regards
David
--
David Bateman Dav...@mo...
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
|
|
From: William P. Y. H. <wil...@gm...> - 2005-12-09 10:29:02
Attachments:
cell2mat.m
|
On 12/9/05, David Bateman <Dav...@mo...> wrote:
> >Yes, I also think the above should work (logical -> numeric). Also, I
> >think char arrays should be allowed (using ascii). What do you think?
> >
> >
> >
> Promotion of type is implicit in the concatenation operation. If cat
> allows it so should cell2mat in my opinion. Therefore just letting cat
> generate the error messages for an illegal concatenation of types makes
> sense to me, as it will report the two offending types in the
> concatenation operation. I believe this means that cell2mat needs no
> changes...
>
OK, so I wouldn't have to change the inner workings of cell2mat.m. But
I've modified the license string ("This program" -> "Octave") and
coding style to better match Octave's coding style, so I would need
Laurent to approve it (is his email correct?).
--
William Poetra Yoga Hadisoeseno
|
|
From: William P. Y. H. <wil...@gm...> - 2005-12-09 10:54:43
Attachments:
cell2mat.m
|
On a second thought, let's not modify the license text ;) |
|
From: William P. Y. H. <wil...@gm...> - 2005-12-14 02:01:58
Attachments:
cell2mat.m.txt
cell2mat.changelog.txt
|
Part of the discussion on octave-dev follows:
On 12/9/05, David Bateman <Dav...@mo...> wrote:
> William Poetra Yoga Hadisoeseno wrote:
>
> >On 12/9/05, David Bateman <Dav...@mo...> wrote:
> >
> >
> >>Again, why? Here is matlab's output
> >>
> >> >> C =3D {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
> >> >> cell2mat(C)
> >>??? Error using =3D=3D> cat
> >>CAT arguments dimensions are not consistent.
> >>
> >>Error in =3D=3D> cell2mat at 92
> >> m{n} =3D cat(2,c{n,:});
> >>
> >>The error message seems to indicate that matlab just lets cat generate
> >>the error as well.
> >>
> >>
> >>
> >
> >Well, in that case then we should just let cat do the job ;)
> >
> >
> >
> >>Matlab doesn't respect their own documentation either
> >>
> >> >> C =3D {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
> >> >> cell2mat(C)
> >>
> >>ans =3D
> >>
> >> 1 2 3 4
> >> 5 6 7 8
> >> 9 10 11 12
> >>
> >>This is with R14sp2..
> >>
> >>
> >>
> >
> >OK, this is consistent with the old (current) cell2mat.
> >
> >
> >
> >> >> C =3D {[1;2],ones(2,2)=3D=3D1}
> >>
> >>C =3D
> >>
> >> [2x1 double] [2x2 logical]
> >>
> >> >> cell2mat(C)
> >>??? Error using =3D=3D> cell2mat
> >>All contents of the input cell array must be of the same data type.
> >>
> >>However, this seems stupid to me, as logical arrays are supposed to be
> >>promoted to double in normal usage... I'd prefer that the above remaine=
d
> >>legal..
> >>
> >>
> >>
> >
> >Yes, I also think the above should work (logical -> numeric). Also, I
> >think char arrays should be allowed (using ascii). What do you think?
> >
> >
> >
> Promotion of type is implicit in the concatenation operation. If cat
> allows it so should cell2mat in my opinion. Therefore just letting cat
> generate the error messages for an illegal concatenation of types makes
> sense to me, as it will report the two offending types in the
> concatenation operation. I believe this means that cell2mat needs no
> changes...
>
> Regards
> David
>
>
> --
> David Bateman Dav...@mo...
> Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>
>
It seems that no one has objections at this point, so I'm braving
myself to submit this file (imported from octave-forge). The file is
attached.
--
William Poetra Yoga Hadisoeseno
|
|
From: John W. E. <jw...@be...> - 2005-12-14 03:01:35
|
On 14-Dec-2005, William Poetra Yoga Hadisoeseno wrote: | It seems that no one has objections at this point, so I'm braving | myself to submit this file (imported from octave-forge). The file is | attached. I included this function. Thanks, jwe |
|
From: Laurent M. <lau...@mo...> - 2006-01-13 17:17:04
Attachments:
cell2mat.m
|
On Thu, 8 Dec 2005 21:31:56 +0800
William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
...
Hi,
Sorry I'm late to comment the post.
First, I found a bug on 1D cell argument (file attached). I will update the
octave-forge version as soon I managed to boot again my own coputer (HD
controler broken :-( )
Seconldy, I read the code you added for dimension and type checking but I don't
think it's efficient for a such function. This type of function has to been run
as fast as possible and usualy no-ones care of the error message (except
during the debugging process). From my point of view, cell2mat don't have to
waste time on input checking.
Laurent
--
Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
Tel: +33 1 69 35 48 30 =-=-=-=-=-=-=-= Email: lau...@mo...
|
|
From: Paul K. <pki...@us...> - 2006-01-14 05:58:08
Attachments:
cell2mat.patch
|
Laurent,
I applied your fix to octave-forge.
Someone with a working 2.9.x will have to check if the fix is needed
there as well. Here's the test:
assert (cell2mat({1, 2, 3}), [1, 2, 3]);
assert (cell2mat({1; 2; 3}), [1; 2; 3]);
See attached for Laurent's fix as a patch to the current octave CVS.
* general/cell2mat.m: support 1D cell argument.
- Paul
On Jan 13, 2006, at 12:16 PM, Laurent Mazet wrote:
> On Thu, 8 Dec 2005 21:31:56 +0800
> William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
> ...
>
> Hi,
>
> Sorry I'm late to comment the post.
>
> First, I found a bug on 1D cell argument (file attached). I will
> update the
> octave-forge version as soon I managed to boot again my own coputer (HD
> controler broken :-( )
>
> Seconldy, I read the code you added for dimension and type checking
> but I don't
> think it's efficient for a such function. This type of function has to
> been run
> as fast as possible and usualy no-ones care of the error message
> (except
> during the debugging process). From my point of view, cell2mat don't
> have to
> waste time on input checking.
>
> Laurent
> --
> Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de
> MOTOROLA
> Tel: +33 1 69 35 48 30 =-=-=-=-=-=-=-= Email:
> lau...@mo...
> <cell2mat.m>
|
|
From: Etienne G. <et...@cs...> - 2006-01-14 08:07:35
|
Hello,
both cell2mat({1, 2, 3}) and cell2mat({1; 2; 3}) fail w/ 2.9.3.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
octave:12> cell2mat({1; 2; 3})
*** cat:
-- Built-in Function: cat (DIM, ARRAY1, ARRAY2, ..., ARRAYN)
Return the concatenation of N-d array objects, ARRAY1, ARRAY2,
..., ARRAYN along dimension DIM.
[snip]
See also: horzcat and vertcat.
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
`/home/etienne/prog/octave/octave-forge/octave-forge/main/cell/cell2mat.m=
'
octave:12> cell2mat({1, 2, 3})
*** cat:
-- Built-in Function: cat (DIM, ARRAY1, ARRAY2, ..., ARRAYN)
Return the concatenation of N-d array objects, ARRAY1, ARRAY2,
..., ARRAYN along dimension DIM.
[snip]
error: evaluating assignment expression near line 69, column 5
error: called from `cell2mat'in file
`/home/etienne/prog/octave=F8ctave-forge/octave-forge/main/cell/cell2mat.=
m'
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
version is 2.9.3, home-compiled. More info needed?
Hth,
Etienne
On Sat, Jan 14, 2006 at 12:57:57AM -0500, Paul Kienzle wrote:
# Laurent,
#=20
# I applied your fix to octave-forge.
#=20
# Someone with a working 2.9.x will have to check if the fix is needed
# there as well. Here's the test:
#=20
# assert (cell2mat({1, 2, 3}), [1, 2, 3]);
# assert (cell2mat({1; 2; 3}), [1; 2; 3]);
#=20
# See attached for Laurent's fix as a patch to the current octave CVS.
#=20
# * general/cell2mat.m: support 1D cell argument.
#=20
# - Paul
#=20
# On Jan 13, 2006, at 12:16 PM, Laurent Mazet wrote:
#=20
# >On Thu, 8 Dec 2005 21:31:56 +0800
# >William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
# >...
# >
# >Hi,
# >
# >Sorry I'm late to comment the post.
# >
# >First, I found a bug on 1D cell argument (file attached). I will=20
# >update the
# >octave-forge version as soon I managed to boot again my own coputer (H=
D
# >controler broken :-( )
# >
# >Seconldy, I read the code you added for dimension and type checking=20
# >but I don't
# >think it's efficient for a such function. This type of function has to=
=20
# >been run
# >as fast as possible and usualy no-ones care of the error message=20
# >(except
# >during the debugging process). From my point of view, cell2mat don't=20
# >have to
# >waste time on input checking.
# >
# > Laurent
# >--=20
# >Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de=20
# >MOTOROLA
# >Tel: +33 1 69 35 48 30 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Email:=20
# >lau...@mo...
# ><cell2mat.m>
#=20
#=20
--=20
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
|
|
From: William P. Y. H. <wil...@gm...> - 2006-01-15 02:51:22
|
On 1/14/06, Laurent Mazet <lau...@mo...> wrote: > > First, I found a bug on 1D cell argument (file attached). I will update t= he > octave-forge version as soon I managed to boot again my own coputer (HD > controler broken :-( ) > David Bateman says this is a bug fixed in 2.9.x :) > Seconldy, I read the code you added for dimension and type checking but I= don't > think it's efficient for a such function. This type of function has to be= en run > as fast as possible and usualy no-ones care of the error message (except > during the debugging process). From my point of view, cell2mat don't have= to > waste time on input checking. > Well, OK, since cat will let us know if there's a problem. Would you like to submit the patch to bug-octave? I'm on a trip, so I might not be able to post a fix until this weekend. -- William Poetra Yoga Hadisoeseno |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X