Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
sorting arrays in a cell array

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 13 Nov, 2012 15:22:11

Message: 1 of 24

Is there a way to sort a cell array of numeric arrays?

I have an N-by-1 cell array, where the cells contains numeric arrays of different lengths (hence the cell array). I'd like to sort them in order of their first elements.

This is an illegal statement that sort of captures what I'm trying to do:

>> sort([myCellArray{:}(1)])

I could do this in a for-loop, of course, but if there's a more Matlab-correct way to do it, I'd like to know.

Subject: sorting arrays in a cell array

From: dpb

Date: 13 Nov, 2012 15:53:01

Message: 2 of 24

On 11/13/2012 9:22 AM, Bruce Elliott wrote:
> Is there a way to sort a cell array of numeric arrays?
>
> I have an N-by-1 cell array, where the cells contains numeric arrays of
> different lengths (hence the cell array). I'd like to sort them in order
> of their first elements.
>
> This is an illegal statement that sort of captures what I'm trying to do:
>
>>> sort([myCellArray{:}(1)])
>
> I could do this in a for-loop, of course, but if there's a more
> Matlab-correct way to do it, I'd like to know.

All that comes to mind would be to use multi--level indexing as above
but to an temporary variable then sort that saving the (optional) index
return value then use it to rearrange the cells...

Actually my release doesn't have the multi-level indexing implemented so
I can't test it but it would be what you have above augmented (methinks,
air code)--

[~,ix]=sort([myCellArray{:}(1)]);
newCell=myCellArray(ix);

--

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 13 Nov, 2012 16:01:20

Message: 3 of 24

dpb <none@non.net> wrote in message <k7tqec$9mm$1@speranza.aioe.org>...
> All that comes to mind would be to use multi--level indexing as above
> but to an temporary variable then sort that saving the (optional) index
> return value then use it to rearrange the cells...
>
> Actually my release doesn't have the multi-level indexing implemented so
> I can't test it but it would be what you have above augmented (methinks,
> air code)--
>
> [~,ix]=sort([myCellArray{:}(1)]);
> newCell=myCellArray(ix);
>
> --
Well, that's just it - I'd like to do that, but that sort() statement above is illegal.

Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do myCellArray{1}(1), but the {:} is not allowed in combination with the (1).

Subject: sorting arrays in a cell array

From: dpb

Date: 13 Nov, 2012 16:13:07

Message: 4 of 24

On 11/13/2012 10:01 AM, Bruce Elliott wrote:
...

> Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do
> myCellArray{1}(1), but the {:} is not allowed in combination with the (1).

Well that pretty much sucks--looks like time for enhancement request.

That's a pretty major weakness in multi-level indexing if you can't
generalize it.

Oh, wait a minute--can you use {:} first, _then_ the {1} and get the
contents? Again, my release has none of this so I have no hands on
experience at all w/ the multi-level stuff...

--

Subject: sorting arrays in a cell array

From: Ben

Date: 13 Nov, 2012 17:22:14

Message: 5 of 24

dpb <none@non.net> wrote in message <k7trk4$cmj$1@speranza.aioe.org>...
> On 11/13/2012 10:01 AM, Bruce Elliott wrote:
> ...
>
> > Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do
> > myCellArray{1}(1), but the {:} is not allowed in combination with the (1).
>
> Well that pretty much sucks--looks like time for enhancement request.
>
> That's a pretty major weakness in multi-level indexing if you can't
> generalize it.
>
> Oh, wait a minute--can you use {:} first, _then_ the {1} and get the
> contents? Again, my release has none of this so I have no hands on
> experience at all w/ the multi-level stuff...
>
> --

This is something I've wanted for a long time. I usually just use a for loop. If you can switch the indices or use a multi-indexed cell array, these indexing approaches are legal:

myCellArray{1}(:)
myCellArray{:,1}

Subject: sorting arrays in a cell array

From: james bejon

Date: 13 Nov, 2012 18:10:22

Message: 6 of 24

% Is this what you mean?

% DATA
X = cell(4, 1);
X{1} = rand(3, 1);
X{2} = rand(3, 1);
X{3} = rand(3, 1);
X{4} = rand(3, 1);

% ENGINE
e1 = arrayfun(@(i) X{i}(1), 1:numel(X));
[~, O] = sort(e1);
X = X(O);

Subject: sorting arrays in a cell array

From: Nasser M. Abbasi

Date: 13 Nov, 2012 18:59:25

Message: 7 of 24

On 11/13/2012 12:10 PM, james bejon wrote:
> % Is this what you mean?
>
> % DATA
> X = cell(4, 1);
> X{1} = rand(3, 1);
> X{2} = rand(3, 1);
> X{3} = rand(3, 1);
> X{4} = rand(3, 1);
>
> % ENGINE
> e1 = arrayfun(@(i) X{i}(1), 1:numel(X));
> [~, O] = sort(e1);
> X = X(O);
>


You can simplify your engine to this. No need for arrayfun

e1 = [X{:}];
[~, O] = sort(e1(1,:));
Y2 = X(O);

--Nasser

Subject: sorting arrays in a cell array

From: james bejon

Date: 13 Nov, 2012 19:15:17

Message: 8 of 24

"Nasser M. Abbasi" <nma@12000.org> wrote in message <k7u5ab$650$1@speranza.aioe.org>...
> On 11/13/2012 12:10 PM, james bejon wrote:
> > % Is this what you mean?
> >
> > % DATA
> > X = cell(4, 1);
> > X{1} = rand(3, 1);
> > X{2} = rand(3, 1);
> > X{3} = rand(3, 1);
> > X{4} = rand(3, 1);
> >
> > % ENGINE
> > e1 = arrayfun(@(i) X{i}(1), 1:numel(X));
> > [~, O] = sort(e1);
> > X = X(O);
> >
>
>
> You can simplify your engine to this. No need for arrayfun
>
> e1 = [X{:}];
> [~, O] = sort(e1(1,:));
> Y2 = X(O);
>
> --Nasser

True. Though there's a post (somewhere) that mentions that the arrays contained in each X{i} might be of different lengths.

Still--I suppose there'd be a workaround.

Something like this perhaps (tho untested)

% DATA
X = cell(4, 1);
X{1} = rand(3, 1);
X{2} = rand(2, 1);
X{3} = rand(3, 1);
X{4} = rand(5, 1);

% EXTRACT FIRST ELEMENTS
ind = cumsum(cellfun(@length, X));
ind = ind(1:end-1)+1;
Y = cat(1, X{:});
disp(Y(ind))

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 13 Nov, 2012 21:04:18

Message: 9 of 24

"james bejon" wrote in message <k7u685$k6m$1@newscl01ah.mathworks.com>...
> "Nasser M. Abbasi" <nma@12000.org> wrote in message <k7u5ab$650$1@speranza.aioe.org>...
> > You can simplify your engine to this. No need for arrayfun
> >
> > e1 = [X{:}];
> > [~, O] = sort(e1(1,:));
> > Y2 = X(O);
> >
> > --Nasser
>
> True. Though there's a post (somewhere) that mentions that the arrays contained in each X{i} might be of different lengths.

Yes, my original post at the top of this thread mentioned that I have the potential to have numeric array of different dimensions in the cells of my cell array, as James goes on to define below:

>
> Still--I suppose there'd be a workaround.
>
> Something like this perhaps (tho untested)
>
> % DATA
> X = cell(4, 1);
> X{1} = rand(3, 1);
> X{2} = rand(2, 1);
> X{3} = rand(3, 1);
> X{4} = rand(5, 1);
>
> % EXTRACT FIRST ELEMENTS
> ind = cumsum(cellfun(@length, X));
> ind = ind(1:end-1)+1;
> Y = cat(1, X{:});
> disp(Y(ind))

Thanks for the responses. I'm not as adept as I should be with cellfun or arrayfun, so I had not considered this kind of approach.

As it happens, my array are not likely to be large, no more than ten or twenty cells containing numeric arrays, most of which will be 2-by-1, but some might be 2-by-n, where n<10. My main concern is therefore not so much performance as it is complexity of code and easy maintainability by other users who might have less expertise with Matlab programming.

In other words, I'm thinking the for-loop might not be such a bad trade-off, if I can't do the one-line version.

Subject: sorting arrays in a cell array

From: Steven_Lord

Date: 14 Nov, 2012 14:59:55

Message: 10 of 24



"dpb" <none@non.net> wrote in message news:k7trk4$cmj$1@speranza.aioe.org...
> On 11/13/2012 10:01 AM, Bruce Elliott wrote:
> ...
>
>> Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do
>> myCellArray{1}(1), but the {:} is not allowed in combination with the
>> (1).
>
> Well that pretty much sucks--looks like time for enhancement request.
>
> That's a pretty major weakness in multi-level indexing if you can't
> generalize it.

One reason why that's not allowed: there's no guarantee that any particular
cell of myCellArray contains a 1st element.

myCellArray = {1:10, [], 11, 12}

If I were just displaying:

>> myCellArray{:}(1)

what should be displayed? Should it error right away (only displaying once
the command is fully executed) or should it display the first element of the
comma-separated list then throw the error?

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: sorting arrays in a cell array

From: Steven_Lord

Date: 14 Nov, 2012 15:04:46

Message: 11 of 24



"Bruce Elliott" <bruce.elliott@jhuapl.nospam.edu> wrote in message
news:k7ucki$g0e$1@newscl01ah.mathworks.com...
> "james bejon" wrote in message <k7u685$k6m$1@newscl01ah.mathworks.com>...
>> "Nasser M. Abbasi" <nma@12000.org> wrote in message
>> <k7u5ab$650$1@speranza.aioe.org>...

*snip*

> Thanks for the responses. I'm not as adept as I should be with cellfun or
> arrayfun, so I had not considered this kind of approach.

Another CELLFUN approach:

firstElementsOfEachCell = cellfun(@(x) x(1), myCellArray); % This will error
if any of the cells are empty
[~, indices] = sort(firstElementsOfEachCell);

and now use indices to reorder the cell array as per the previous
suggestions.

> As it happens, my array are not likely to be large, no more than ten or
> twenty cells containing numeric arrays, most of which will be 2-by-1, but
> some might be 2-by-n, where n<10. My main concern is therefore not so much
> performance as it is complexity of code and easy maintainability by other
> users who might have less expertise with Matlab programming.
> In other words, I'm thinking the for-loop might not be such a bad
> trade-off, if I can't do the one-line version.

For such a small problem, if you preallocate firstElementsOfEachCell, using
the FOR loop to extract the first elements of each cell would probably be
more efficient (CELLFUN being a much bigger hammer than you need) and easier
to read.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 15:05:25

Message: 12 of 24

On 11/14/2012 8:59 AM, Steven_Lord wrote:
>
>
> "dpb" <none@non.net> wrote in message
> news:k7trk4$cmj$1@speranza.aioe.org...
>> On 11/13/2012 10:01 AM, Bruce Elliott wrote:
>> ...
>>
>>> Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do
>>> myCellArray{1}(1), but the {:} is not allowed in combination with the
>>> (1).
>>
...

>> That's a pretty major weakness in multi-level indexing if you can't
>> generalize it.
>
> One reason why that's not allowed: there's no guarantee that any
> particular cell of myCellArray contains a 1st element.
>
...

> what should be displayed? Should it error right away (only displaying
> once the command is fully executed) or should it display the first
> element of the comma-separated list then throw the error?

I'll throw it back the other way--why should that a user could have a
data error prevent the use of a construct generically even when it often
may not have such an error and is useful?

There are many ways one can have an error besides this one.

--

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 15:37:02

Message: 13 of 24

On 11/14/2012 9:04 AM, Steven_Lord wrote:
...

> For such a small problem, if you preallocate firstElementsOfEachCell,
> using the FOR loop to extract the first elements of each cell would
> probably be more efficient (CELLFUN being a much bigger hammer than you
> need) and easier to read.

But isn't it a bigger hammer would be the generalized multi-level index?

<gd&r> :)

--

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 15:51:12

Message: 14 of 24

On 11/14/2012 8:59 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:k7trk4$cmj$1@speranza.aioe.org...
>> On 11/13/2012 10:01 AM, Bruce Elliott wrote:
>> ...
>>
>>> Actually, it's the syntax myCellArray{:}(1) that's illegal. You can do
>>> myCellArray{1}(1), but the {:} is not allowed in combination with the
>>> (1).
>>
...
>> That's a pretty major weakness in multi-level indexing if you can't
>> generalize it.
>
> One reason why that's not allowed: there's no guarantee that any
> particular cell of myCellArray contains a 1st element.
>
> myCellArray = {1:10, [], 11, 12}
>
> If I were just displaying:
>
>>> myCellArray{:}(1)
>
> what should be displayed? Should it error right away (only displaying
> once the command is fully executed) or should it display the first
> element of the comma-separated list then throw the error?

Why should it (necessarily) error at all? Why couldn't/shouldn't it
display a list the length of which would be
sum(~isempty(myCellArray{:}(1)))?

It would be up to user to determine whether this is/is not what
intended, not the toolset. Again, back to the idea that it's the user's
responsibility not to abuse a tool rather than the vendor's to try to
protect him from the possibility of self-shooting.foot

--

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 19:56:27

Message: 15 of 24

On 11/14/2012 8:59 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:k7trk4$cmj$1@speranza.aioe.org...
...

>> That's a pretty major weakness in multi-level indexing if you can't
>> generalize it.
>
> One reason why that's not allowed: there's no guarantee that any
> particular cell of myCellArray contains a 1st element.
...

One last comment...

If one takes the above reason for proscription to its conclusion the
same is also true when use any one given fixed index as well...so it's
ok to get an empty result for a single subscript but not for multiple.
Doesn't make a convincing argument to me.

--

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 14 Nov, 2012 20:53:07

Message: 16 of 24

"Steven_Lord" <slord@mathworks.com> wrote in message >
> For such a small problem, if you preallocate firstElementsOfEachCell, using
> the FOR loop to extract the first elements of each cell would probably be
> more efficient (CELLFUN being a much bigger hammer than you need) and easier
> to read.

Exactly right. As it happens, there are other benefits to an explicit FOR loop in this particular case, so that's what I'm doing. The CELLFUN approach is still a good one to keep in mind for future problems, though.

Bruce

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 14 Nov, 2012 21:12:06

Message: 17 of 24

dpb <none@non.net> wrote in message <k80dsi$8a7$2@speranza.aioe.org>...
> On 11/14/2012 9:04 AM, Steven_Lord wrote:
> ...
>
> > For such a small problem, if you preallocate firstElementsOfEachCell,
> > using the FOR loop to extract the first elements of each cell would
> > probably be more efficient (CELLFUN being a much bigger hammer than you
> > need) and easier to read.
>
> But isn't it a bigger hammer would be the generalized multi-level index?
>
> <gd&r> :)

I'm still not sure exactly what you mean by a "multi-level index", which you stated earlier that you don't have in your version of Matlab. Do you mean the ability to write something like,

x = myCellArray{3,4}(5,6); ?

That's just a basic bit cell array functionality, which has been around a pretty long time, I believe. (I can't remember when cell arrays were first introduced, which ought to mean that it was quite a while ago, although lately it doesn't mean that quite the way it used to ...)

If you want to make an array of doubles by doing something like

x = myCellArray{:}(3,:);

however, that's really another matter all together, since one of the main reasons to have cell arrays is the ability to mix types, so making a normal array (e.g. a numerical array) array out of elements of a cell array is not necessarily something we should be able to do.

You might have an empty array in one of your cells, as Steve pointed out above, but you could also have a mix of real, complex, string, or logical arrays all in one cell array, so how would you understand an array of elements from this cell array?

I realize that I'm now answering my own original post, but I think it would somewhat violate the intent of cell arrays to do what I asked. If I know up front that I have an array of arrays of doubles, then a multi-dimensional array is possibly what I should be using, so instead of

x = myCellArray{:}(3,:);

I would have

x = myBigArray(:,3,:);

If my sub-arrays have different sizes, then I'd have to pad them with NaNs, but at least I'd be able to do the kind of array manipulation we're discussing.

Bruce

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 21:47:38

Message: 18 of 24

On 11/14/2012 3:12 PM, Bruce Elliott wrote:
...

> I'm still not sure exactly what you mean by a "multi-level index", which
> you stated earlier that you don't have in your version of Matlab. Do you
> mean the ability to write something like,
>
> x = myCellArray{3,4}(5,6); ?
>
> That's just a basic bit cell array functionality, which has been around
> a pretty long time, I believe. (I can't remember when cell arrays were
> first introduced, which ought to mean that it was quite a while ago,
> although lately it doesn't mean that quite the way it used to ...)

<http://www.mathworks.com/help/matlab/matlab_prog/multilevel-indexing-to-access-parts-of-cells.html>

It's _now_ "basic" cell array functionality but it wasn't for at least a
couple of releases after cell arrays were first introduced.

Cell arrays existed at least as far back as R11; I'm currently at R12
which is roughly '99/'00 time frame. But the second level of indexing
('multi-level') wasn't introduced until sometime after that. If I do

 >> c(2,3)={rand(4)}
c =
      [] [] []
      [] [] [4x4 double]
 >> c(2,3)
ans =
     [4x4 double]
 >> c(2,3){1,1}
??? Error: () Indexing must appear last in an index expression.

 >>

You see I can't write the second set of indices; can only access the
contents of the cells indirectly or in toto...can do the curly braces
thing on the cell, but that's as good as it gets at this release level.

 >> c{2,3}
ans =
     0.9355 0.0579 0.1389 0.2722
     0.9169 0.3529 0.2028 0.1988
     0.4103 0.8132 0.1987 0.0153
     0.8936 0.0099 0.6038 0.7468
 >>

 >> ver
--------------------------------------------------
MATLAB Version 6.0.0.88 (R12) on PCWIN
MATLAB License Number: --XXXXX--
--------------------------------------------------
MATLAB Toolbox Version 6.0 (R12)
06-Oct-2000
Signal Processing Toolbox Version 5.0 (R12)
01-Jun-2000
 >>

That's why I was (am still am) surprised that one can't generalize the
multi-level indexing even if the possibility of there being empty
cells--it seems like an unwarranted attempt to try to protect the user
from something they should have the ability to do and worry about
protecting their instead.

--

Subject: sorting arrays in a cell array

From: Steven_Lord

Date: 14 Nov, 2012 22:21:16

Message: 19 of 24



"dpb" <none@non.net> wrote in message news:k813je$4hr$1@speranza.aioe.org...
> On 11/14/2012 3:12 PM, Bruce Elliott wrote:
> ...
>
>> I'm still not sure exactly what you mean by a "multi-level index", which
>> you stated earlier that you don't have in your version of Matlab. Do you
>> mean the ability to write something like,
>>
>> x = myCellArray{3,4}(5,6); ?
>>
>> That's just a basic bit cell array functionality, which has been around
>> a pretty long time, I believe. (I can't remember when cell arrays were
>> first introduced, which ought to mean that it was quite a while ago,
>> although lately it doesn't mean that quite the way it used to ...)
>
> <http://www.mathworks.com/help/matlab/matlab_prog/multilevel-indexing-to-access-parts-of-cells.html>
>
> It's _now_ "basic" cell array functionality but it wasn't for at least a
> couple of releases after cell arrays were first introduced.
>
> Cell arrays existed at least as far back as R11; I'm currently at R12
> which is roughly '99/'00 time frame.

Cell arrays were introduced in MATLAB 5.0 (R10). For reference some of the
other features introduced in that release, according to the WHATSNEW
function, were:

struct arrays
multidimensional arrays
the original MATLAB object system
SWITCH
WARNING
subfunctions
ODE solvers

> But the second level of indexing ('multi-level') wasn't introduced until
> sometime after that. If I do
>
> >> c(2,3)={rand(4)}
> c =
> [] [] []
> [] [] [4x4 double]
> >> c(2,3)
> ans =
> [4x4 double]
> >> c(2,3){1,1}
> ??? Error: () Indexing must appear last in an index expression.

That still doesn't work. Use c{2, 3}(1, 1) instead. I tried it and it works
in release R10.

*snip*

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: sorting arrays in a cell array

From: dpb

Date: 14 Nov, 2012 22:36:29

Message: 20 of 24

On 11/14/2012 4:21 PM, Steven_Lord wrote:
> c{2, 3}(1, 1)

Well, I'll be... :)

I'd never found that and I guess I never would've. There's no
subsection in the documentation specifically on the nomenclature and
when I'd tried before I'd never found the (apparently only) one line
wherein it is actually mentioned...I hadn't caught onto the meaning of
the error being that the curlies had to be first (and my old eyes are to
the point I have a heckuva' time distinguishing them from plain old
paren's anymore... :( ) but had always (for like 10+ yrs) presumed it
just didn't like the second set of addressing tacked on since never
could find "multi-level indexing" in a search...

So, OK, I stand corrected and I could've used cells much more
efficiently than have in the past having finally gotten that can.

But I _still_ think not being able to general the cell references is a
mistake.

--

Subject: sorting arrays in a cell array

From: Bruce Elliott

Date: 15 Nov, 2012 14:23:06

Message: 21 of 24

dpb <none@non.net> wrote in message <k816f0$be5$1@speranza.aioe.org>...
> On 11/14/2012 4:21 PM, Steven_Lord wrote:
> > c{2, 3}(1, 1)
>
> Well, I'll be... :)
>
> I'd never found that and I guess I never would've. There's no
> subsection in the documentation specifically on the nomenclature and
> when I'd tried before I'd never found the (apparently only) one line
> wherein it is actually mentioned...I hadn't caught onto the meaning of
> the error being that the curlies had to be first (and my old eyes are to
> the point I have a heckuva' time distinguishing them from plain old
> paren's anymore... :( ) but had always (for like 10+ yrs) presumed it
> just didn't like the second set of addressing tacked on since never
> could find "multi-level indexing" in a search...
>
> So, OK, I stand corrected and I could've used cells much more
> efficiently than have in the past having finally gotten that can.
Ah! Okay, now I understand some of your previous statement more clearly. Yes the curly braces can take a while to master - I run into that all the time with new Matlab users.

This: c(2,3){1,1} would imply that c is a "normal" array (all one type) because of the straight parens, but that the (2,3) element of that array contains a cell array -- because of the {1,1} -- which is not allowed.

You parse this: c{2,3}(1,1) as, "c is a cell array (because it's indexed via curly braces); c{2,3} is the content of the cell with indices {2,3}; c{2,3}(1,1) is the first element of the array contained in the cell at c{2,3}.

The most confusing thing is that both c(2,3) and c{2,3} are allowed, but they are not the same. c(2,3) is a cell (always), but c{2,3} is the contents of that cell, so its type depends on what's stored there.

That's why you get (running your example myself, so different rand output):

>> c(2,3) = {rand(4)};
>> c(2,3)
ans =
    [4x4 double]

>> c{2,3}
ans =
    0.8147 0.6324 0.9575 0.9572
    0.9058 0.0975 0.9649 0.4854
    0.1270 0.2785 0.1576 0.8003
    0.9134 0.5469 0.9706 0.1419

>
> But I _still_ think not being able to general the cell references is a
> mistake.
By that, I take it you mean the "{:}" construct, e.g. C{:}(1,1). (?)

I think that's the only thing missing.

- Bruce

Subject: sorting arrays in a cell array

From: Steven_Lord

Date: 15 Nov, 2012 15:06:07

Message: 22 of 24



"Bruce Elliott" <bruce.elliott@jhuapl.nospam.edu> wrote in message
news:k82tsa$7n9$1@newscl01ah.mathworks.com...
> dpb <none@non.net> wrote in message <k816f0$be5$1@speranza.aioe.org>...
>> On 11/14/2012 4:21 PM, Steven_Lord wrote:
>> > c{2, 3}(1, 1)
>>
>> Well, I'll be... :)
>>
>> I'd never found that and I guess I never would've. There's no subsection
>> in the documentation specifically on the nomenclature and when I'd tried
>> before I'd never found the (apparently only) one line wherein it is
>> actually mentioned...I hadn't caught onto the meaning of the error being
>> that the curlies had to be first (and my old eyes are to the point I have
>> a heckuva' time distinguishing them from plain old paren's anymore...
>> :( ) but had always (for like 10+ yrs) presumed it just didn't like the
>> second set of addressing tacked on since never could find "multi-level
>> indexing" in a search...

Yes, increasing the discoverability of the full power of MATLAB is a
difficult problem. I've heard from some people that give training classes or
lectures that sometimes they'll show a feature and no one in the class knows
about it. Not so bad if the feature came out in the most recent release ...
bad when it was introduced five years ago. [Publishing is one feature that's
often slipped through the cracks.] There isn't really a good answer as far
as I'm aware, but we're trying.

>> So, OK, I stand corrected and I could've used cells much more efficiently
>> than have in the past having finally gotten that can.
> Ah! Okay, now I understand some of your previous statement more clearly.
> Yes the curly braces can take a while to master - I run into that all the
> time with new Matlab users.
>
> This: c(2,3){1,1} would imply that c is a "normal" array (all one type)
> because of the straight parens, but that the (2,3) element of that array
> contains a cell array -- because of the {1,1} -- which is not allowed.
>
> You parse this: c{2,3}(1,1) as, "c is a cell array (because it's indexed
> via curly braces); c{2,3} is the content of the cell with indices {2,3};
> c{2,3}(1,1) is the first element of the array contained in the cell at
> c{2,3}.
>
> The most confusing thing is that both c(2,3) and c{2,3} are allowed, but
> they are not the same. c(2,3) is a cell (always), but c{2,3} is the
> contents of that cell, so its type depends on what's stored there.

In almost all cases, y = x(indices) is of the same type as x itself. [For
function handles, x(indices) actually evaluates the function handle and so y
is of the type that function returns. Object authors can do whatever makes
sense for their objects and so this guideline may not apply to all objects.]

Curly brace indexing is only defined for cell arrays (and objects where the
authors have chosen to implement it) and the result of curly brace indexing
is of whatever type is stored INSIDE the cells.

> That's why you get (running your example myself, so different rand
> output):
>
>>> c(2,3) = {rand(4)};
>>> c(2,3)
> ans = [4x4 double]
>
>>> c{2,3}
> ans =
> 0.8147 0.6324 0.9575 0.9572
> 0.9058 0.0975 0.9649 0.4854
> 0.1270 0.2785 0.1576 0.8003
> 0.9134 0.5469 0.9706 0.1419

Yes. If you wrote:

clear c d
c(2, 3) = {rand(4)};
d{2, 3} = rand(4);
y = c(2, 3);
z = d{2, 3};

you should see in the output of "whos c d y z" that c and d are cell arrays,
y is a cell array, and z is a double array.

>> But I _still_ think not being able to general the cell references is a
>> mistake.
> By that, I take it you mean the "{:}" construct, e.g. C{:}(1,1). (?)
>
> I think that's the only thing missing.

I'm not sure if there are other considerations preventing that from working;
the example I gave was an off-the-top-of-my-head issue. If you feel strongly
that this construct should be supported in MATLAB, please let Technical
Support know and let them know how you would use it if it existed. The more
actual user use cases the developers have when designing a piece of
functionality, the higher the likelihood that it'll actually do what the
users want when or if it's implemented.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: sorting arrays in a cell array

From: dpb

Date: 15 Nov, 2012 16:04:49

Message: 23 of 24

On 11/15/2012 8:23 AM, Bruce Elliott wrote:
> dpb <none@non.net> wrote in message <k816f0$be5$1@speranza.aioe.org>...
...

>> ...I hadn't caught onto the meaning of
>> the error being that the curlies had to be first (and my old eyes are
>> to the point I have a heckuva' time distinguishing them from plain old
>> paren's anymore... :( ) but had always (for like 10+ yrs) presumed it
>> just didn't like the second set of addressing tacked on since never
>> could find "multi-level indexing" in a search...
>>
...

> Ah! Okay, now I understand some of your previous statement more clearly.
> Yes the curly braces can take a while to master - I run into that all
> the time with new Matlab users.
...

Well, my problem wasn't so much mastering the curlies as recognizing
that the release actually even supported the extended addressing mode at
all--what TMW now calls "multi-level addressing".

I'm hardly new to Matlab having used it more or less regularly since
before the introduction of the Windows version--and at some times
depending on the particular work (being in general consulting I had a
wide variety of tasks--sometimes Matlab was central other times it had
no part). The difficulty was that I made a mistake once upon a time
apparently and misinterpreted the error to mean that only one set of
indices could be used and chalked that up to this version/release not
(yet) supporting the advanced dereferencing.

I _do_ recall at one time seeing the 'multi-level' buzzword and
searching for it in the help files and never finding it so that simply
reinforced my (now obviously mistaken) impression that I just had a
release that didn't support that particular syntax. Owing to many
factors the prime of which is that I have retired from active technical
consulting and returned to the family farm it has not been
cost-effective to upgrade so I am at a disadvantage w/ newer features
but it's entertainment to kinda' keep a hand in by monitoring cs-sm...

>> But I _still_ think not being able to general the cell references is a
>> mistake.
> By that, I take it you mean the "{:}" construct, e.g. C{:}(1,1). (?)
>
> I think that's the only thing missing.

Yes, typed "general" where meant "generalize"

As I noted in the responses to Steven, I tend to be of the camp it's the
user's job to ensure the code fits the data and vice versa rather than
that of the compiler to too restrictively prevent errors and thereby
prevent useful constructs from even being possible just because they
could be misused or occasionally error.

--

Subject: sorting arrays in a cell array

From: dpb

Date: 15 Nov, 2012 16:16:56

Message: 24 of 24

On 11/15/2012 9:06 AM, Steven_Lord wrote:
...

>>> I'd never found that and I guess I never would've. ...
>>> since never could find "multi-level indexing" in a search...
>
> Yes, increasing the discoverability of the full power of MATLAB is a
> difficult problem. I've heard from some people that give training
> classes or lectures that sometimes they'll show a feature and no one in
> the class knows about it. Not so bad if the feature came out in the most
> recent release ... bad when it was introduced five years ago.
> [Publishing is one feature that's often slipped through the cracks.]
> There isn't really a good answer as far as I'm aware, but we're trying.

I don't disagree on both counts--in this area certainly the expanded
help that includes a new subtopic and examples is much better and should
be no excuse for users now to not at least be aware of it. Of course,
that means that users have to actually use the documentation which seems
to be an ever-growing problem.

For those of us of my age that dealt w/ large code input decks of
multiple boxes of cards where the only instruction on preparing that was
a printed manual, the idea of reading documentation in detail and for
every nuance possible to glean therefrom, it's routine. Even by the
time I left that area many years ago now, the ability of new
graduates/new hires to apparently even understand the concept rather
than expecting some point 'n click magic osmosis to happen was most
discouraging. It has only gotten worse since it seems.

...

>>> But I _still_ think not being able to general the cell references is
>>> a mistake.
>> By that, I take it you mean the "{:}" construct, e.g. C{:}(1,1). (?)
>>
>> I think that's the only thing missing.
>
> I'm not sure if there are other considerations preventing that from
> working; the example I gave was an off-the-top-of-my-head issue. If you
> feel strongly that this construct should be supported in MATLAB, please
> let Technical Support know and let them know how you would use it if it
> existed. The more actual user use cases the developers have when
> designing a piece of functionality, the higher the likelihood that it'll
> actually do what the users want when or if it's implemented.

Steven, as I noted in the counter arguments against preventing it (also
otomh and I grant it's a complex-enough area that there may be some real
parsing and other issues that would take a goodly amount of analysis to
address thoroughly) as a concept to me it is all about completeness and
similarity (orthogonality).

Trying to envision the usage in particular is one way to add some
impetus but like many things if one doesn't have the facility at all
then one won't look for ways to use it but the obverse--avoid a design
for data structures that obviates the need instead.

--

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us