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:
I'm dense, but...somebody 'splain accumarray() please?

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 5 Jul, 2013 19:42:57

Message: 1 of 24

I've only relatively recently acquired recent-enough release to have
accumarray(). Despite my efforts the documentation for it seems to
remain totally opaque to me.

So,

a) Anybody know of any more detailed tutorial/description than that of
the online doc's? Mayhaps the old dog could eventually learn the new
trick w/ another bone to chase, and

b) I was trying to build an index array of the vector 1:k, w/ each row
1:n being one greater than that in the preceding row. I brute-forced it
w/ repmat() and cumsum() but seems like accumarray ought to be the tool.
But, all my efforts were totally unsuccessful (and for the most part I
couldn't even precisely decipher why got what did get)...

So, how to build the following, say...

[1 2 3; 2 3 4; 4 5 6; ...]

?

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 5 Jul, 2013 19:49:55

Message: 2 of 24

On 7/5/2013 2:42 PM, dpb wrote:
...

> So, how to build the following, say...
>
> [1 2 3; 2 3 4; 4 5 6; ...]

Dagnabbit...the above was to been

[1 2 3; 2 3 4; 3 4 5; ...]

of course... :(

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: james bejon

Date: 6 Jul, 2013 09:48:09

Message: 3 of 24

% As I understand it, accumarray takes a list of indexes ("subs") and a list of values ("vals"). The output is an array of some kind. The subs tell the function where to put the vals in the final array. Vals assigned to the same sub are then aggregated according to the passed function (the 4th argument). So, if I have subs of [2 3 6 6] with a value of 1, I'll get [0 1 1 0 0 2] as my output:

subs = [2 3 6 6].';
vals = 1;
disp(accumarray(subs, vals))

% The rest just builds up from there.

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Steven_Lord

Date: 8 Jul, 2013 15:42:55

Message: 4 of 24



"dpb" <none@non.net> wrote in message news:kr77js$1e2$1@speranza.aioe.org...
> I've only relatively recently acquired recent-enough release to have
> accumarray(). Despite my efforts the documentation for it seems to remain
> totally opaque to me.
>
> So,
>
> a) Anybody know of any more detailed tutorial/description than that of the
> online doc's? Mayhaps the old dog could eventually learn the new trick w/
> another bone to chase, and

Have you used the accumulation behavior of SPARSE in the past?

rows = [1; 1; 1; 2; 3];
cols = [1; 1; 2; 3; 3];
values = [1; 2; 3; 4; 5];
A = full(sparse(rows, cols, values))

You'll note that element A(1, 1) is 3 = 1+2. The two elements of values
corresponding to rows == 1 & cols == 1 are added by SPARSE and stored in
A(1, 1).

http://www.mathworks.com/help/matlab/ref/sparse.html

"Any elements of s that have duplicate values of i and j are added
together."

The simplest syntax for ACCUMARRAY does basically the same thing, modulo
specifying rows and columns as a matrix instead of two vectors (since
ACCUMARRAY can create N-D arrays out of indices matrices with N columns
while SPARSE is limited to 2-D matrices.)

B = accumarray([rows, cols], values)

B should be the same as A (since I converted A from sparse to full.)

When you specify a FUN input to ACCUMARRAY, ACCUMARRAY will use that
function instead of (essentially) using @sum to accumulate the values.

C = accumarray([rows, cols], values, [], @mean)

C(1, 1) will be mean([1 2]) in this case, unlike B(1, 1) which was sum([1
2]).

> b) I was trying to build an index array of the vector 1:k, w/ each row 1:n
> being one greater than that in the preceding row. I brute-forced it w/
> repmat() and cumsum() but seems like accumarray ought to be the tool.

Actually, for this I'd use BSXFUN instead of ACCUMARRAY if I understand what
you're describing.

k = 3;
n = 6;
D = bsxfun(@plus, (1:k), (1:n).')

D(r, c) is the rth element of (1:n).' plus the cth element of (1:k),
computed without explicitly blowing up (1:k) and (1:n).' into n-by-k
matrices.

> But, all my efforts were totally unsuccessful (and for the most part I
> couldn't even precisely decipher why got what did get)...
>
> So, how to build the following, say...
>
> [1 2 3; 2 3 4; 4 5 6; ...]

With the correction from your later post, see above.

As an application example for ACCUMARRAY, let's say you measured a specific
quantity (volume of a song) and binned it into discrete levels.

n = 100;
stateVector = randi([1 10], [n 1]); % This does NOT go to 11 ;)

You want to identify how many times the song goes from volume x to volume y.

first = (1:n-1).';
second = first+1;
coordinates = stateVector([first, second]);
transitions = accumarray(coordinates, ones(n-1, 1));

Element (r, c) of transitions will indicate how many times stateVector
contained the vector [r; c], since we'll add the corresponding elements of
ones(n-1, 1) together to form that element of transitions. To check, find
those transitions:

locateTransitions = @(r, c) find(stateVector(first) == r &
stateVector(second) == c);

The output of locateTransitions(r, c) should be of length transitions(r, c).

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

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 8 Jul, 2013 20:45:11

Message: 5 of 24

On 7/8/2013 10:42 AM, Steven_Lord wrote:
...

> Have you used the accumulation behavior of SPARSE in the past?

Nope; I've _rarely_ even used sparse as my problems generally didn't fit
that space...

Thanks for the notes, Steven; I'll study them at length and maybe the
lightbulb will come on.

BTW, I'm beginning to get mind around accumarray, cellfun, bsxfun and
friends but they're all also new toys w/ the release 2012b that didn't
have access to before. Plus, of course, anonymous functions and all
that entails... :) And, since day job is farming and this is just
playing, the amount of time to really devote isn't great...

It does seem to me that the amount of basic explanatory text in relation
to the specific syntax has dropped significantly w/ the new help
documentation combined w/ the explosion in functionality. It seems like
the "Getting Started" documentation could/(should?) probably grow by
order of magnitude for such features.

> rows = [1; 1; 1; 2; 3];
> cols = [1; 1; 2; 3; 3];
> values = [1; 2; 3; 4; 5];
> A = full(sparse(rows, cols, values))
>
> You'll note that element A(1, 1) is 3 = 1+2. The two elements of values
> corresponding to rows == 1 & cols == 1 are added by SPARSE and stored in
> A(1, 1).
>
> http://www.mathworks.com/help/matlab/ref/sparse.html
>
> "Any elements of s that have duplicate values of i and j are added
> together."
>
> The simplest syntax for ACCUMARRAY does basically the same thing, modulo
> specifying rows and columns as a matrix instead of two vectors (since
> ACCUMARRAY can create N-D arrays out of indices matrices with N columns
> while SPARSE is limited to 2-D matrices.)
>
> B = accumarray([rows, cols], values)
>
> B should be the same as A (since I converted A from sparse to full.)
>
> When you specify a FUN input to ACCUMARRAY, ACCUMARRAY will use that
> function instead of (essentially) using @sum to accumulate the values.
>
> C = accumarray([rows, cols], values, [], @mean)
>
> C(1, 1) will be mean([1 2]) in this case, unlike B(1, 1) which was
> sum([1 2]).
>
>> b) I was trying to build an index array of the vector 1:k, w/ each row
>> 1:n being one greater than that in the preceding row. I brute-forced
>> it w/ repmat() and cumsum() but seems like accumarray ought to be the
>> tool.
>
> Actually, for this I'd use BSXFUN instead of ACCUMARRAY if I understand
> what you're describing.
>
> k = 3;
> n = 6;
> D = bsxfun(@plus, (1:k), (1:n).')
>
> D(r, c) is the rth element of (1:n).' plus the cth element of (1:k),
> computed without explicitly blowing up (1:k) and (1:n).' into n-by-k
> matrices.
>
>> But, all my efforts were totally unsuccessful (and for the most part I
>> couldn't even precisely decipher why got what did get)...
>>
>> So, how to build the following, say...
>>
>> [1 2 3; 2 3 4; 4 5 6; ...]
>
> With the correction from your later post, see above.
>
> As an application example for ACCUMARRAY, let's say you measured a
> specific quantity (volume of a song) and binned it into discrete levels.
>
> n = 100;
> stateVector = randi([1 10], [n 1]); % This does NOT go to 11 ;)
>
> You want to identify how many times the song goes from volume x to
> volume y.
>
> first = (1:n-1).';
> second = first+1;
> coordinates = stateVector([first, second]);
> transitions = accumarray(coordinates, ones(n-1, 1));
>
> Element (r, c) of transitions will indicate how many times stateVector
> contained the vector [r; c], since we'll add the corresponding elements
> of ones(n-1, 1) together to form that element of transitions. To check,
> find those transitions:
>
> locateTransitions = @(r, c) find(stateVector(first) == r &
> stateVector(second) == c);
>
> The output of locateTransitions(r, c) should be of length transitions(r,
> c).
>

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Steven_Lord

Date: 9 Jul, 2013 15:00:24

Message: 6 of 24



"dpb" <none@non.net> wrote in message news:krf8cj$5kh$1@speranza.aioe.org...
> On 7/8/2013 10:42 AM, Steven_Lord wrote:
> ...
>
>> Have you used the accumulation behavior of SPARSE in the past?
>
> Nope; I've _rarely_ even used sparse as my problems generally didn't fit
> that space...
>
> Thanks for the notes, Steven; I'll study them at length and maybe the
> lightbulb will come on.

If it helps, think of ACCUMARRAY as sort of a "binning" tool like HIST. All
the values with the same row of indices in subs get shoved into the same bin
and then each bin gets processed into a scalar.

> BTW, I'm beginning to get mind around accumarray, cellfun, bsxfun and
> friends but they're all also new toys w/ the release 2012b that didn't
> have access to before. Plus, of course, anonymous functions and all that
> entails... :) And, since day job is farming and this is just playing, the
> amount of time to really devote isn't great...

If you've used inline functions, anonymous functions are at their most basic
similar: a way to write one expression as a function without requiring you
to create a separate function file or subfunction. However I feel anonymous
functions are more flexible and more powerful, in particular when it comes
to composition.

f = @(x) x.^2; % square x
g = @(x) sin(x)+cos(x);
h = @(x) g(f(x)); % sin(x.^2)+cos(x.^2)
h(0:5)

To do that with inline functions would be more complicated and the calling
syntax would be much less simple. [*]

> It does seem to me that the amount of basic explanatory text in relation
> to the specific syntax has dropped significantly w/ the new help
> documentation combined w/ the explosion in functionality. It seems like
> the "Getting Started" documentation could/(should?) probably grow by order
> of magnitude for such features.

It's a balancing act. If the table of contents for the "Getting Started"
documentation looks like the TOC for War and Peace, it would be intimidating
for new users. In addition, ACCUMARRAY is not exactly what I would call an
introductory function. I think few people will jump right in and start using
ACCUMARRAY their first day.

I think the mental model for the documentation staff for "Getting Started"
is what do new users need in order to get them started using MATLAB. As I
look at Getting Started now, all of the topics seem like things that a new
user may need to do in their first week of using MATLAB. The basics of
working with the Desktop? Sure, absolutely. Matrices and Arrays? Can't do
much in MATLAB without them. Indexing? Ditto.

Maybe we need an "Intermediate MATLAB Programming" documentation section
that discusses some of the more advanced topics, like matrix
creation/manipulation with BSXFUN, ACCUMARRAY, etc.? What do others think?

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

[*]
f2 = inline('x.^2', 'x');
g2 = inline('sin(x)+cos(x)', 'x');
h2 = inline('g(f(x))', 'x', 'f', 'g'); % Note h2 must accept three inputs,
not one like h did
h2(0:5, f2, g2)
 

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 9 Jul, 2013 16:00:04

Message: 7 of 24

On 7/9/2013 10:00 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:krf8cj$5kh$1@speranza.aioe.org...

...[snip the code snippets for brevity...thanks, I'll study them, too]...

>> It does seem to me that the amount of basic explanatory text in
>> relation to the specific syntax has dropped significantly w/ the new
>> help documentation combined w/ the explosion in functionality. It
>> seems like the "Getting Started" documentation could/(should?)
>> probably grow by order of magnitude for such features.
>
> It's a balancing act. If the table of contents for the "Getting Started"
> documentation looks like the TOC for War and Peace, it would be
> intimidating for new users. In addition, ACCUMARRAY is not exactly what
> I would call an introductory function. I think few people will jump
> right in and start using ACCUMARRAY their first day.
>
> I think the mental model for the documentation staff for "Getting
> Started" is what do new users need in order to get them started using
> MATLAB. As I look at Getting Started now, all of the topics seem like
> things that a new user may need to do in their first week of using
> MATLAB. The basics of working with the Desktop? Sure, absolutely.
> Matrices and Arrays? Can't do much in MATLAB without them. Indexing? Ditto.
>
> Maybe we need an "Intermediate MATLAB Programming" documentation section
> that discusses some of the more advanced topics, like matrix
> creation/manipulation with BSXFUN, ACCUMARRAY, etc.? What do others think?

Perhaps...I don't disagree necessarily that "Getting Started" isn't the
right place, only that it's what there is in the organization.

What I find most frustrating w/ the documentation as a long-time user
trying to come to grips w/ the new features in a relatively limited
amount of time which I think sorta' emulates a new user w/ a real
problem rather than the undergraduate student in first programming
course is that there isn't a top-level TOC any longer that is visible as
before except by having to physically revert to it and that, at least to
me, it seems as though the narrative material that is background is much
more difficult to find than previously.

I'll swear I've seen some in-depth descriptions of some feature that I
managed to get to somehow, but later when trying to find it I can't seem
to get that particular section back no matter how I try to find it.
Unfortunately, I can't put my finger on a specific example to illustrate
directly; I just know it has happened on more than one subject having to
do w/ data structures primarily. Perhaps part of that is having to do
w/ now having some toolboxes that never had before so now I've got a new
class or two that tend to get mixed into the search results and so
sometimes maybe what I've gotten into had to do w/, say, the Statistics
dataset object when what I had been looking at was details of structures...

I agree, 'tis a quandary and the TMW could easily spend 10X the budget
on documentation and still not cover everything everybody would like.

I do think the new format is a step backwards, however. I've had some
offline conversations w/ other TMW staff who were/are the contact for
the current version license arrangement in that regard who has promised
to take the comments to heart. Now, whether there's any hope of any
redirection in the ways in which I think it should go I've no idea...I
have no way of knowing how my feedback and impressions match up w/ those
from any other users.

I am, however, while occasionally frustrated, trying to be sure that all
my complaints have some constructive input in direction towards how I
would prefer to see the area improved/changed/resolved...

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Marc

Date: 10 Jul, 2013 06:21:10

Message: 8 of 24

dpb <none@non.net> wrote in message <krhc24$h9h$1@speranza.aioe.org>...
> On 7/9/2013 10:00 AM, Steven_Lord wrote:
> > "dpb" <none@non.net> wrote in message
> > news:krf8cj$5kh$1@speranza.aioe.org...
>
> ...[snip the code snippets for brevity...thanks, I'll study them, too]...
>
> >> It does seem to me that the amount of basic explanatory text in
> >> relation to the specific syntax has dropped significantly w/ the new
> >> help documentation combined w/ the explosion in functionality. It
> >> seems like the "Getting Started" documentation could/(should?)
> >> probably grow by order of magnitude for such features.
> >
> > It's a balancing act. If the table of contents for the "Getting Started"
> > documentation looks like the TOC for War and Peace, it would be
> > intimidating for new users. In addition, ACCUMARRAY is not exactly what
> > I would call an introductory function. I think few people will jump
> > right in and start using ACCUMARRAY their first day.
> >
> > I think the mental model for the documentation staff for "Getting
> > Started" is what do new users need in order to get them started using
> > MATLAB. As I look at Getting Started now, all of the topics seem like
> > things that a new user may need to do in their first week of using
> > MATLAB. The basics of working with the Desktop? Sure, absolutely.
> > Matrices and Arrays? Can't do much in MATLAB without them. Indexing? Ditto.
> >
> > Maybe we need an "Intermediate MATLAB Programming" documentation section
> > that discusses some of the more advanced topics, like matrix
> > creation/manipulation with BSXFUN, ACCUMARRAY, etc.? What do others think?
>
> Perhaps...I don't disagree necessarily that "Getting Started" isn't the
> right place, only that it's what there is in the organization.
>
> What I find most frustrating w/ the documentation as a long-time user
> trying to come to grips w/ the new features in a relatively limited
> amount of time which I think sorta' emulates a new user w/ a real
> problem rather than the undergraduate student in first programming
> course is that there isn't a top-level TOC any longer that is visible as
> before except by having to physically revert to it and that, at least to
> me, it seems as though the narrative material that is background is much
> more difficult to find than previously.
>
> I'll swear I've seen some in-depth descriptions of some feature that I
> managed to get to somehow, but later when trying to find it I can't seem
> to get that particular section back no matter how I try to find it.
> Unfortunately, I can't put my finger on a specific example to illustrate
> directly; I just know it has happened on more than one subject having to
> do w/ data structures primarily. Perhaps part of that is having to do
> w/ now having some toolboxes that never had before so now I've got a new
> class or two that tend to get mixed into the search results and so
> sometimes maybe what I've gotten into had to do w/, say, the Statistics
> dataset object when what I had been looking at was details of structures...
>
> I agree, 'tis a quandary and the TMW could easily spend 10X the budget
> on documentation and still not cover everything everybody would like.
>
> I do think the new format is a step backwards, however. I've had some
> offline conversations w/ other TMW staff who were/are the contact for
> the current version license arrangement in that regard who has promised
> to take the comments to heart. Now, whether there's any hope of any
> redirection in the ways in which I think it should go I've no idea...I
> have no way of knowing how my feedback and impressions match up w/ those
> from any other users.
>
> I am, however, while occasionally frustrated, trying to be sure that all
> my complaints have some constructive input in direction towards how I
> would prefer to see the area improved/changed/resolved...
>

This point was brought up in Jan Simon's question about how users feel about the "new" Matlab interface. This is a hard pill to swallow for me as well, as I have not only promoted Matlab over the years, but raved about how excellent the documentation WAS!

I still have 2010a on my laptop, mostly for the documentation.

That said, this new documentation is a hard sell and no longer something I rave about.

This needs to be fixed. There is no shame in going back. Hopefully the Mathworks is not too big to say, maybe this was a mistake.

On a functional note, the help system feels like I run into dead ends. I end up on some page and trying to go back a step seems not possible. So, I need to go back to the command line, after closing out the help browser, and arrow up to start again...

No fixing this. The old documentation was awesome. No need to change.

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Kim Andrews

Date: 10 Jul, 2013 14:00:40

Message: 9 of 24

This might not help you, but I thought I'd chime in on how I've been using
the documentation.

I almost never use the TOC, and navigate almost exclusively using the "bread
crumbs" that appear under the search box at the top of the page. I think
this gets me to the topic categories in the fewest number of clicks. So if
I am on the sparse reference page
http://www.mathworks.com/help/matlab/ref/sparse.html but need more
information, and maybe a full page example, I click the "Sparse Matrix
Creation" link at the top of the page to get more information (the category
page). Another level up in the bread crumb gets me access to more
information than just creating a sparse matrix.

I use doc and docsearch from the command line a lot. I think the icons in
the search results do a good job of guiding me to a function reference page
or to a category page or a full page example. I also find it useful to be
able to filter results to just MATLAB and not the toolboxes (or vice versa).

If you find that you're getting particularly lost in the documentation, use
the "Was this topic helpful?" link on the bottom of the page and fill out
the text fields. That feedback does get read!

Kim

"Marc " <marc.schreier@uop.com> wrote in message
news:kriugm$men$1@newscl01ah.mathworks.com...
> dpb <none@non.net> wrote in message <krhc24$h9h$1@speranza.aioe.org>...
>> On 7/9/2013 10:00 AM, Steven_Lord wrote:
>> > "dpb" <none@non.net> wrote in message
>> > news:krf8cj$5kh$1@speranza.aioe.org...
>>
>> ...[snip the code snippets for brevity...thanks, I'll study them, too]...
>>
>> >> It does seem to me that the amount of basic explanatory text in
>> >> relation to the specific syntax has dropped significantly w/ the new
>> >> help documentation combined w/ the explosion in functionality. It
>> >> seems like the "Getting Started" documentation could/(should?)
>> >> probably grow by order of magnitude for such features.
>> >
>> > It's a balancing act. If the table of contents for the "Getting
>> > Started"
>> > documentation looks like the TOC for War and Peace, it would be
>> > intimidating for new users. In addition, ACCUMARRAY is not exactly what
>> > I would call an introductory function. I think few people will jump
>> > right in and start using ACCUMARRAY their first day.
>> >
>> > I think the mental model for the documentation staff for "Getting
>> > Started" is what do new users need in order to get them started using
>> > MATLAB. As I look at Getting Started now, all of the topics seem like
>> > things that a new user may need to do in their first week of using
>> > MATLAB. The basics of working with the Desktop? Sure, absolutely.
>> > Matrices and Arrays? Can't do much in MATLAB without them. Indexing?
>> > Ditto.
>> >
>> > Maybe we need an "Intermediate MATLAB Programming" documentation
>> > section
>> > that discusses some of the more advanced topics, like matrix
>> > creation/manipulation with BSXFUN, ACCUMARRAY, etc.? What do others
>> > think?
>>
>> Perhaps...I don't disagree necessarily that "Getting Started" isn't the
>> right place, only that it's what there is in the organization.
>>
>> What I find most frustrating w/ the documentation as a long-time user
>> trying to come to grips w/ the new features in a relatively limited
>> amount of time which I think sorta' emulates a new user w/ a real problem
>> rather than the undergraduate student in first programming course is that
>> there isn't a top-level TOC any longer that is visible as before except
>> by having to physically revert to it and that, at least to me, it seems
>> as though the narrative material that is background is much more
>> difficult to find than previously.
>>
>> I'll swear I've seen some in-depth descriptions of some feature that I
>> managed to get to somehow, but later when trying to find it I can't seem
>> to get that particular section back no matter how I try to find it.
>> Unfortunately, I can't put my finger on a specific example to illustrate
>> directly; I just know it has happened on more than one subject having to
>> do w/ data structures primarily. Perhaps part of that is having to do w/
>> now having some toolboxes that never had before so now I've got a new
>> class or two that tend to get mixed into the search results and so
>> sometimes maybe what I've gotten into had to do w/, say, the Statistics
>> dataset object when what I had been looking at was details of
>> structures...
>>
>> I agree, 'tis a quandary and the TMW could easily spend 10X the budget on
>> documentation and still not cover everything everybody would like.
>>
>> I do think the new format is a step backwards, however. I've had some
>> offline conversations w/ other TMW staff who were/are the contact for the
>> current version license arrangement in that regard who has promised to
>> take the comments to heart. Now, whether there's any hope of any
>> redirection in the ways in which I think it should go I've no idea...I
>> have no way of knowing how my feedback and impressions match up w/ those
>> from any other users.
>>
>> I am, however, while occasionally frustrated, trying to be sure that all
>> my complaints have some constructive input in direction towards how I
>> would prefer to see the area improved/changed/resolved...
>>
>
> This point was brought up in Jan Simon's question about how users feel
> about the "new" Matlab interface. This is a hard pill to swallow for me
> as well, as I have not only promoted Matlab over the years, but raved
> about how excellent the documentation WAS!
> I still have 2010a on my laptop, mostly for the documentation.
>
> That said, this new documentation is a hard sell and no longer something I
> rave about.
>
> This needs to be fixed. There is no shame in going back. Hopefully the
> Mathworks is not too big to say, maybe this was a mistake.
>
> On a functional note, the help system feels like I run into dead ends. I
> end up on some page and trying to go back a step seems not possible. So,
> I need to go back to the command line, after closing out the help browser,
> and arrow up to start again...
>
> No fixing this. The old documentation was awesome. No need to change.

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 17:51:16

Message: 10 of 24

On 7/10/2013 9:00 AM, Kim Andrews wrote:
> This might not help you, but I thought I'd chime in on how I've been
> using the documentation.
>
> I almost never use the TOC, and navigate almost exclusively using the
> "bread crumbs" that appear under the search box at the top of the page.
> I think this gets me to the topic categories in the fewest number of
> clicks. So if I am on the sparse reference page
> http://www.mathworks.com/help/matlab/ref/sparse.html but need more
> information, and maybe a full page example, I click the "Sparse Matrix
> Creation" link at the top of the page to get more information (the
> category page). Another level up in the bread crumb gets me access to
> more information than just creating a sparse matrix.
>
> I use doc and docsearch from the command line a lot. I think the icons
> in the search results do a good job of guiding me to a function
> reference page or to a category page or a full page example. I also find
> it useful to be able to filter results to just MATLAB and not the
> toolboxes (or vice versa).
...

I do a lot of the same; my complaint is that that is still more work
than the old way and I still think it's extremely useful to see the TOC
w/o it blocking the rest of the help text in order to see where one is
in the hierarchy.

I agree the filtering on product/toolbox is useful; I don't see that it
requires the loss of the previously better organization to add that.

It's also disconcerting that the doc actually crashes and occasionally
takes the whole Matlab session with it...never had that happen before.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 18:09:46

Message: 11 of 24

On 7/9/2013 10:00 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:krf8cj$5kh$1@speranza.aioe.org...
>> On 7/8/2013 10:42 AM, Steven_Lord wrote:
>> ...
...

> If it helps, think of ACCUMARRAY as sort of a "binning" tool like HIST.
> All the values with the same row of indices in subs get shoved into the
> same bin and then each bin gets processed into a scalar.
>
>> BTW, I'm beginning to get mind around accumarray, cellfun, bsxfun and
>> friends...

OK, I've managed to write a few answers w/ accumarray and cellfun now; I
had actually gotten moderately comfortable w/ bsxfun earlier in the
summer while tutoring an intern long distance...

Now, a slight diversion/extension -- is there any syntax that will
allow for building a cell array whose contents in each cell are (say) a
variable-length vector w/ the cell being addressed like accumarray or
cellfun?

Specifically there's a question at Answers now where the poster is
looking to identify a set of contiguous numbers ordered by a second
index variable. His actual request was nebulous to begin with so I
started w/ returning a logical of which subset was/wasn't contiguous--

 >> [u,~,c] = unique(a(:,3));
 >> lcontig=accumarray(c,a(:,4),[],@(x) all(abs(diff(x))==1))
lcontig =
    1
    0
    0
 >>

That wasn't what the requestor actually wanted; amplified the question
to say needed the number of missing values in each subsection. That's
also easy enough...just change the function a little--

 >> nmiss=accumarray(c,a(:,4),[],@(x) length([min(x):max(x)])-length(x))
nmiss =
    0
    1
    2
 >>

OK, that's background; here's the question -- what if the desire is now
expanded to know who's missing in the set [min(x):max(x)] above? That
can be from the empty set to a set of nmiss and the logical way to
return the results would be a cell array of that length for each group.

I can't seem to find any syntax outside the loop that works.

As a secondary to that, is there any syntax by which one can eliminate
the need for the temporary to hold the alternate optional return value
from the call to unique() above? This would be useful in general, far
more than just in accumarray and friends.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Eric Sampson

Date: 10 Jul, 2013 18:22:08

Message: 12 of 24

dpb <none@non.net> wrote in message <krk817$fg$1@speranza.aioe.org>...
> On 7/9/2013 10:00 AM, Steven_Lord wrote:
> > "dpb" <none@non.net> wrote in message
> > news:krf8cj$5kh$1@speranza.aioe.org...
> >> On 7/8/2013 10:42 AM, Steven_Lord wrote:
> >> ...
> ...
(snip)
>
> As a secondary to that, is there any syntax by which one can eliminate
> the need for the temporary to hold the alternate optional return value
> from the call to unique() above? This would be useful in general, far
> more than just in accumarray and friends.
>
> --

I must be being dense too ;) because didn't you already show in your example that you can use the ~ operator to ignore return values, like [~,~,c] = unique(a(:,3)); or am I misunderstanding your question?

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Kelly Kearney

Date: 10 Jul, 2013 18:35:07

Message: 13 of 24


> OK, I've managed to write a few answers w/ accumarray and cellfun now; I
> had actually gotten moderately comfortable w/ bsxfun earlier in the
> summer while tutoring an intern long distance...
>
> Now, a slight diversion/extension -- is there any syntax that will
> allow for building a cell array whose contents in each cell are (say) a
> variable-length vector w/ the cell being addressed like accumarray or
> cellfun?
>

I forget how the hell I learned this trick, because the documentation for the SZ input to accumarray is confusing at best (rereading it now, it still doesn't make any sense to me, even knowing what the effect is). Anyway, to get cell array output from your example, add that third input, and make sure your function returns a cell array:

>> a = [1 1 1 2 2 2 2 3 3 3];
>> b = [1 2 3 4 5 8 10 5 6 8];
>> [u,~,c] = unique(a);

>> groups = accumarray(c,b, [length(u) 1], @(x) {x})
>> missing = accumarray(c,b, [length(u) 1], @(x) {setdiff(min(x):max(x), x)})

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 18:38:22

Message: 14 of 24

On 7/10/2013 1:22 PM, Eric Sampson wrote:
...

> I must be being dense too ;) because didn't you already show in your
> example that you can use the ~ operator to ignore return values, like
> [~,~,c] = unique(a(:,3)); or am I misunderstanding your question?

But I had to save c in order to pass it to the following invocation of
arrayfun().

It would be _a_good_thing_ since that's the only reason for c to not to
have to create it in the workplace or local context an have it hanging
around but rather to have it be a temporary by nesting the function calls.

If it were u that were needed/wanted as the argument, then it could be done.

Sometimes, if the function result is need more than once then it makes
sense to make the temporary to avoid repeated evaluations, of course
(there's where enhancing the optimizer comes in if it can recognize
common expressions and eliminate the second call or not).

That help, hopefully?

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 19:19:20

Message: 15 of 24

On 7/10/2013 1:35 PM, Kelly Kearney wrote:
...

> I forget how the hell I learned this trick, because the documentation
> for the SZ input to accumarray is confusing at best (rereading it now,
> it still doesn't make any sense to me, even knowing what the effect is).
> Anyway, to get cell array output from your example, add that third
> input, and make sure your function returns a cell array:
>
>>> a = [1 1 1 2 2 2 2 3 3 3];
>>> b = [1 2 3 4 5 8 10 5 6 8];
>>> [u,~,c] = unique(a);
>
>>> groups = accumarray(c,b, [length(u) 1], @(x) {x})
>>> missing = accumarray(c,b, [length(u) 1], @(x) {setdiff(min(x):max(x),
>>> x)})

Brilliant!!! :)

I agree on the doc re: SZ argument; I puzzled over it at length
initially and gave up. I've not yet pursued all of Steven's in depth
enough to know if that helps on that point or not but thanks...this
really solves several things have seen recently.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 19:21:45

Message: 16 of 24

On 7/10/2013 12:51 PM, dpb wrote:
> On 7/10/2013 9:00 AM, Kim Andrews wrote:
>> This might not help you, but I thought I'd chime in on how I've been
>> using the documentation.
>>
>> I almost never use the TOC, and navigate almost exclusively using the
>> "bread crumbs" that appear under the search box at the top of the page.
>> I think this gets me to the topic categories in the fewest number of
>> clicks. ,,,
> ...
>
> I do a lot of the same; my complaint is that that is still more work
> than the old way...

In particular, you have to keep scrolling back to the top; a keystroke
even w/ focus in the help doesn't automagically take you back to the
type-in box and there's no other navigation help other than scrolling.

All in all, it just adds much more overhead in using the product afaict.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Eric Sampson

Date: 10 Jul, 2013 19:22:14

Message: 17 of 24

dpb <none@non.net> wrote in message <krk9mr$5c5$1@speranza.aioe.org>...
> On 7/10/2013 1:22 PM, Eric Sampson wrote:
> ...
>
> > I must be being dense too ;) because didn't you already show in your
> > example that you can use the ~ operator to ignore return values, like
> > [~,~,c] = unique(a(:,3)); or am I misunderstanding your question?
>
> But I had to save c in order to pass it to the following invocation of
> arrayfun().
>
> It would be _a_good_thing_ since that's the only reason for c to not to
> have to create it in the workplace or local context an have it hanging
> around but rather to have it be a temporary by nesting the function calls.
>
> If it were u that were needed/wanted as the argument, then it could be done.
>
> Sometimes, if the function result is need more than once then it makes
> sense to make the temporary to avoid repeated evaluations, of course
> (there's where enhancing the optimizer comes in if it can recognize
> common expressions and eliminate the second call or not).
>
> That help, hopefully?
>
> --

Ah yes, I think that now I understand what you were referring to. Oddly enough, I submitted an enhancement request recently that you might like, to allow a person to do something like this:

lcontig=accumarray([~,~,c] = unique(a(:,3)),a(:,4),[],@(x) all(abs(diff(x))==1))

The temp variable can be named whatever you want, the crux of the enhancement request is to allow you to next function calls with multiple return arguments, as long as all but one return arg are ignored using ~.

If you like that idea, please email/call TMW support and let them know, so they add your vote to the enhancment request :)

Cheers

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 19:54:07

Message: 18 of 24

On 7/10/2013 2:22 PM, Eric Sampson wrote:
> dpb <none@non.net> wrote in message <krk9mr$5c5$1@speranza.aioe.org>...
...

.. wanting a way to hold a temporary variable or other syntax to eliminate
temporaries for optional return variables...

...

> Ah yes, I think that now I understand what you were referring to. Oddly
> enough, I submitted an enhancement request recently that you might like,
> to allow a person to do something like this:
>
> lcontig=accumarray([~,~,c] = unique(a(:,3)),a(:,4),[],@(x)
> all(abs(diff(x))==1))
>
> The temp variable can be named whatever you want, the crux of the
> enhancement request is to allow you to [nest] function calls
> with multiple return arguments, as long as all but one return arg
> areignored using ~.
>
> If you like that idea, please email/call TMW support and let them know,
> so they add your vote to the enhancment request :)

I do; it at least gets one step when need only the one result.
Unfortunately, it isn't flexible-enough to remove the standalone call
when need more than one return value as in the other examples where need
both the list of unique values as well as the index vector.

Not sure there is a general solution, unfortunately.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Kelly Kearney

Date: 10 Jul, 2013 21:30:45

Message: 19 of 24

dpb <none@non.net> wrote in message <krke4s$htn$1@speranza.aioe.org>...
> On 7/10/2013 2:22 PM, Eric Sampson wrote:
> > dpb <none@non.net> wrote in message <krk9mr$5c5$1@speranza.aioe.org>...
> ...
>
> .. wanting a way to hold a temporary variable or other syntax to eliminate
> temporaries for optional return variables...
>
> ...
>
> > Ah yes, I think that now I understand what you were referring to. Oddly
> > enough, I submitted an enhancement request recently that you might like,
> > to allow a person to do something like this:
> >
> > lcontig=accumarray([~,~,c] = unique(a(:,3)),a(:,4),[],@(x)
> > all(abs(diff(x))==1))
> >
> > The temp variable can be named whatever you want, the crux of the
> > enhancement request is to allow you to [nest] function calls
> > with multiple return arguments, as long as all but one return arg
> > areignored using ~.
> >
> > If you like that idea, please email/call TMW support and let them know,
> > so they add your vote to the enhancment request :)
>
> I do; it at least gets one step when need only the one result.
> Unfortunately, it isn't flexible-enough to remove the standalone call
> when need more than one return value as in the other examples where need
> both the list of unique values as well as the index vector.
>
> Not sure there is a general solution, unfortunately.

There is... write a new function. :-)

I got very tired of this accumarray limitation, since almost all my applications of the function involve grouping variables that a) are floating point values, not indices, b) are multi-column (i.e a unique(a, 'rows') sort of situation), and/or c) are cell arrays of strings. Combining (b) and (c) is particularly annoying since unique(x,'rows') somewhat inexplicably can't handle multi-column cell arrays of strings, adding more intermediate steps to get the proper index variable.

So, I wrote my own wrapper for accumarray (aggregate.m) that allows all of the above, cutting out the need for intermediate storage. Posting it to the FEX now; should appear soon. There's also consolidator.m in the FEX, which is also a more flexible version of accumarray but if I remember correctly restricts functions to scalar output.

And regarding the other topic of this thread, I also hate the new documentation. But I've been lamenting changes on that front ever since they eliminated the Index... it's simply gotten worse and worse since then. The crash-Matlab-completely-for-no-apparent-reason feature of the R2013a Help Browser is a particularly nice touch, though. Ugh.

-Kelly

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 22:28:17

Message: 20 of 24

On 7/10/2013 4:30 PM, Kelly Kearney wrote:
> dpb <none@non.net> wrote in message <krke4s$htn$1@speranza.aioe.org>...
>> On 7/10/2013 2:22 PM, Eric Sampson wrote:
>> > dpb <none@non.net> wrote in message <krk9mr$5c5$1@speranza.aioe.org>...
>> ...
>>
>> .. wanting a way to hold a temporary variable or other syntax to
>> eliminate temporaries for optional return variables...
>>
>> ...
...

>> Not sure there is a general solution, unfortunately.
>
> There is... write a new function. :-)
> I got very tired of this accumarray limitation, since almost all my
> applications of the function involve grouping variables that a) are
> floating point values, not indices, b) are multi-column (i.e a unique(a,
> 'rows') sort of situation), and/or c) are cell arrays of strings.
> Combining (b) and (c) is particularly annoying since unique(x,'rows')
> somewhat inexplicably can't handle multi-column cell arrays of strings,
> adding more intermediate steps to get the proper index variable.
>
> So, I wrote my own wrapper for accumarray (aggregate.m) that allows all
> of the above, cutting out the need for intermediate storage. Posting it
> to the FEX now; should appear soon. There's also consolidator.m in the
> FEX, which is also a more flexible version of accumarray but if I
> remember correctly restricts functions to scalar output.

Does it eliminate the intermediary storage or only move it to a level
below the calling function so it does (at least which is _a_good_thing_
(tm) ) vanish silently?

> And regarding the other topic of this thread, I also hate the new
> documentation. But I've been lamenting changes on that front ever since
> they eliminated the Index... it's simply gotten worse and worse since
> then. The crash-Matlab-completely-for-no-apparent-reason feature of the
> R2013a Help Browser is a particularly nice touch, though. Ugh.

That's disheartening to hear it hasn't yet gone away--I found it in R2012b.

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 10 Jul, 2013 23:18:58

Message: 21 of 24

On 7/10/2013 5:28 PM, dpb wrote:
> On 7/10/2013 4:30 PM, Kelly Kearney wrote:
>> dpb <none@non.net> wrote in message
>> <krke4s$htn$1@speranza.aioe.org>...
>>> On 7/10/2013 2:22 PM, Eric Sampson wrote:
>>>> dpb <none@non.net> wrote in message
>>> <krk9mr$5c5$1@speranza.aioe.org>... ...
>>>
>>> .. wanting a way to hold a temporary variable or other syntax to
>>> eliminate temporaries for optional return variables...
>>>
>>> ...
> ...
>
>>> Not sure there is a general solution, unfortunately.
>>
>> There is... write a new function. :-) I got very tired of this
>> accumarray limitation,...

And, actually I forgot to mention again that I see it as a desirable
enhancement beyond just accumarray and friends; I have lots of times
when the index variable or somesuch that is an optional output of many
functions is needed only in order to be immediately consumed by the
following code. It is just inconvenient to have those have to be
non-transitory simply owing to there not being any syntax to avoid it.

I've thought of trying out the idea of a proposal using some additional
scoping mechanism but not to the point of actually trying to get it to
the point of being a serious request for enhancement (and, of course, w/
consideration might decide it's not the way to even suggest).

--

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Steven_Lord

Date: 11 Jul, 2013 14:58:36

Message: 22 of 24



"dpb" <none@non.net> wrote in message news:krkc3l$c3v$1@speranza.aioe.org...
> On 7/10/2013 1:35 PM, Kelly Kearney wrote:
> ...
>
>> I forget how the hell I learned this trick, because the documentation
>> for the SZ input to accumarray is confusing at best (rereading it now,
>> it still doesn't make any sense to me, even knowing what the effect is).
>> Anyway, to get cell array output from your example, add that third
>> input, and make sure your function returns a cell array:
>>
>>>> a = [1 1 1 2 2 2 2 3 3 3];
>>>> b = [1 2 3 4 5 8 10 5 6 8];
>>>> [u,~,c] = unique(a);
>>
>>>> groups = accumarray(c,b, [length(u) 1], @(x) {x})
>>>> missing = accumarray(c,b, [length(u) 1], @(x) {setdiff(min(x):max(x),
>>>> x)})
>
> Brilliant!!! :)
>
> I agree on the doc re: SZ argument; I puzzled over it at length initially
> and gave up. I've not yet pursued all of Steven's in depth enough to know
> if that helps on that point or not but thanks...this really solves several
> things have seen recently.

I didn't discuss the SZ input in my previous explanation; I was more focused
on the subscripts and the FUN input since I expected them to be more
confusing. As you might suspect from the name of the input argument in the
doc, SZ has to do with the size of the output. It allows you to specify that
you want the output to be exactly a certain size. Lets say you had a set of
data like this:

r = [1; 2; 3; 4; 2; 3; 1];
c = [1; 3; 6; 4; 3; 2; 5];
v = [1; 1; 1; 1; 1; 1; 1];

and you need the result of ACCUMARRAY to be a 5-by-6 matrix so it matches
the results of some previous computation. There's no 5 in r so if you did:

A = accumarray([r, c], v)

A would be of size [max(r) max(c)] or in this case 4-by-6. When you tried to
concatenate it with ( [ ] ) or add it to (+) your previous results you'd
receive a dimension mismatch error. If you did:

B = accumarray([r, c], v, [5 6])

B would be 5-by-6 regardless of whether or not r contained a 5 or c
contained a 6. In this case the last row of B is all zeros because there's
no 5 in r. This can also guard you against invalid data. If you know the
output MUST be 5-by-5 and the 6 in c was a typo:

C = accumarray([r, c], v, [5 5])

you would receive an error that states basically that one of the subscripts
was greater than the desired size of the output.

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

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: Kelly Kearney

Date: 11 Jul, 2013 15:03:15

Message: 23 of 24

dpb <none@non.net> wrote in message <krkn62$b02$1@speranza.aioe.org>...

> Does it eliminate the intermediary storage or only move it to a level
> below the calling function so it does (at least which is _a_good_thing_
> (tm) ) vanish silently?

Yeah, it justs moves the index step into function, so you don't need to worry about it. Regarding getting certain outputs only, perhaps a wrapper function like:

%---
function varargout = outnum(fun, idx, varargin)
% fun: handle to function
% idx: output #s you want to keep
% varargin: input variables to the function
varargout = cell(1, max(idx));
[varargout{:}] = fun(varargin{:});
varargout = varargout(idx);
%---

(I haven't tested that thoroughly, but I think it should work).

So, for example:

test = round(rand(20,1)*10);
accumarray(outnum(@unique,3,test), test, [10 1], @(x) {x})

Again, it only moves the collection and disposal of extra output variables to a different workspace, rather than eliminating it altogether, but it would allow for easier one-liners.
Though perhaps pretty difficult-to-read ones (of course, I feel the same way about bsxfun, especially when I have to combine 3 or 4 bsxfun operators in a single equation).


> > And regarding the other topic of this thread, I also hate the new
> > documentation. But I've been lamenting changes on that front ever since
> > they eliminated the Index... it's simply gotten worse and worse since
> > then. The crash-Matlab-completely-for-no-apparent-reason feature of the
> > R2013a Help Browser is a particularly nice touch, though. Ugh.
>
> That's disheartening to hear it hasn't yet gone away--I found it in R2012b.

Ah, well, I skipped straight from 2012a to 2013a, so I'm just discovering it. Unfortunately, I have to upgrade for my site license, or I think I would gladly revert to R2008b, the last version that I felt truly offered me an upgrade.


>
> --

Subject: I'm dense, but...somebody 'splain accumarray() please?

From: dpb

Date: 11 Jul, 2013 17:00:36

Message: 24 of 24

On 7/11/2013 10:03 AM, Kelly Kearney wrote:
> dpb <none@non.net> wrote in message <krkn62$b02$1@speranza.aioe.org>...
>
>> Does it eliminate the intermediary storage or only move it to a level
>> below the calling function so it does (at least which is
>> _a_good_thing_ (tm) ) vanish silently?
>
> Yeah, it justs moves the index step into function, so you don't need to
> worry about it. Regarding getting certain outputs only, perhaps a
> wrapper function like:
>
> %---
> function varargout = outnum(fun, idx, varargin)
> % fun: handle to function
> % idx: output #s you want to keep
> % varargin: input variables to the function
> varargout = cell(1, max(idx));
> [varargout{:}] = fun(varargin{:});
> varargout = varargout(idx);
> %---
>
> (I haven't tested that thoroughly, but I think it should work).
...

OK, I grok that is one way to reduce the top-level explicit deallocation
(and probably the only way w/ current syntax) w/ the perhaps obfuscation
of some code intent. "There is no free lunch." :)
>
>> > And regarding the other topic of this thread, I also hate the new
>> > documentation. But I've been lamenting changes on that front ever since
>> > they eliminated the Index... it's simply gotten worse and worse since
>> > then. The crash-Matlab-completely-for-no-apparent-reason feature of the
>> > R2013a Help Browser is a particularly nice touch, though. Ugh.
>>
>> That's disheartening to hear it hasn't yet gone away--I found it in
>> R2012b.
>
> Ah, well, I skipped straight from 2012a to 2013a, so I'm just
> discovering it. Unfortunately, I have to upgrade for my site license, or
> I think I would gladly revert to R2008b, the last version that I felt
> truly offered me an upgrade.
...

I returned to farm in 2000 and only had a couple years' contracting work
in place, none of which was at all Matlab-intensive, so I hadn't updated
since R12. Consequently is why am just now beginning to learn
accumarray, cellfun, bsxfun and friends since I only got on 2012b about
a year ago and haven't had much time until the heat of this summer and
the severe drought has pretty well shut down farm field work so I've
been piddling a lot more w/ stuff wasn't that familiar with than had been...

--

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