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![]()
> 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