Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: accumarray: Unexpected behavior?
Replies: 3   Last Post: Dec 11, 2013 10:44 AM

 Messages: [ Previous | Next ]
 Paul Posts: 18 Registered: 5/18/11
Re: accumarray: Unexpected behavior?
Posted: Dec 10, 2013 6:20 PM

"Steven Lord" <Steven_Lord@mathworks.com> wrote in message <l8830s\$qfl\$1@newscl01ah.mathworks.com>...
>
> "Paul " <paulremovethispartjackson@jhuapl.edu> wrote in message
> news:l87pku\$ppa\$1@newscl01ah.mathworks.com...

> > From the 2012b doc and verified in Matlab:
> >
> > val = 101:106;
> > subs=[1 2; 1 2; 3 1; 4 1; 4 4; 4 1];
> > B = accumarray(subs,val,[],@(x)sum(diff(x)))
> >
> > B =
> >
> > 0 -1 0 0
> > 0 0 0 0
> > 0 0 0 0
> > 2 0 0 0
> >
> >
> > Why is B(1,2) == -1? Shouldn't B(1,2) = sum(diff([101:102]))?
> >
> > Just like B(4,1) = sum(diff([104;106])).

>
> http://www.mathworks.com/help/matlab/ref/accumarray.html
>
> "Note If the subscripts in subs are not sorted, fun should not depend on
> the order of the values in its input data."
>
> This same note is present in the documentation for release R2012b.
>
> Your subscripts are not sorted (remember, linear indices in MATLAB go down
> the columns first) but your function does depend on the order of the values
> in its input data. Compare B and C, val and val2, and subs and subs2 in the
> code below.
>
> val = 101:106;
> subs=[1 2; 1 2; 3 1; 4 1; 4 4; 4 1];
> B = accumarray(subs,val,[],@(x)sum(diff(x)))
>
> lin = sub2ind([4 4], subs(:, 1), subs(:, 2));
> [~, sortedOrder] = sort(lin);
>
> val2 = val(sortedOrder);
> subs2 = subs(sortedOrder, :);
> C = accumarray(subs2, val2, [], @(x) sum(diff(x)))
>
> --
> Steve Lord
> slord@mathworks.com
> http://www.mathworks.com

Steve,

Thanks for pointing out the note. A few comments/questions:

Based on your example, it would appear that accumarray reserves the right to collect the column vector of elements in each bin in any order it chooses. If subs is sorted it apparently uses the order defined by subs (based on your example, this is not stated in the doc), otherwise it does something else. In light of this, I suggest that the Note should say: The order of the elements in the column vector passed to fun is unspecified; it is recommended that the output of fun should not depend on the order of the elements in its input data. Alternatively, the doc should clarify the guarantee of what will happen if subs is sorted.

Does the term "sorted" in the note mean "sorted by linear index as defined by sub2ind?" If so, this should be stated. We could run your example using [~,sortedOrder]=sortrows(subs) and get a different answer. In fact, when I did that I got C==B. Is that just coincidence?

Most importantly, I pulled this example right out of the doc page. Why would the doc page include an example that is explicitly identified by the Note as bad practice? Unless that was the point of the example, in which case the example should say "here's why you shouldn't do what we just told you not to do."

Now I might be able to go on and figure out the rest of the exampes ;) !

Thanks
Paul

Date Subject Author
12/10/13 Paul
12/10/13 Steven Lord
12/10/13 Paul
12/11/13 Steven Lord