Since R2013a, unique() retrieves first occurrence: where in the docs?
3 Ansichten (letzte 30 Tage)
Ältere Kommentare anzeigen
The release notes 2013a state the change of the set functions, but I can't seem to find the info in the documentation of unique(). Where does it say that the default behaviour retrieves the first occurrence?
IMHO the recent trend with the documentation has not only reduced it's usability, e.g. rearranged the TOC (ok we will get used to it), broken links, compressed sections (one additional click to expand all to find stuff), but it also delivers incomplete info.
EDIT
- Release notes 2012a announce future change in set functions.
- Release notes 2013a state change in set functions to 'first'.
EDIT 13 May 2013
I received prompt feedback from the documentation team and they confirmed that the help will be updated.
3 Kommentare
Antworten (1)
Jan
am 30 Sep. 2013
Bearbeitet: Jan
am 30 Sep. 2013
Not an answer, but related to the topic:
The change of such fundamental function is very painful for me. I have to maintain programs with several 100'000 lines of code running on different Matlab versions. I cannot replace all occurrences of unique(.) to unique(., 'last'), because some very old Matlab versions do not support the 'last' flag. It is very time consuming to search in the release notes for the version, in which this flag has been added.
The 'legacy' flag is even less useful: It is supported in the newest Matlab versions only and causes an error in all older versions. Of course there is no universal way to modify old Matlab releases to accept this flag, but a flag to support backward compatibility should ha a certain level of backward compatibility.
The solution is trivial, but tedious: All unique, setdiff etc calls have to be redirected to a user-defined function, which checks the Matlab version at first and adds or remove flags accordingly. Such wrappers are a bad idea for basic Matlab commands.
Especially these set-functions had a large potential for improvements on a completely other point instead of the sorting order: They are inefficient for small data sets with about less than 200 elements. Then the sorting and the binary search waste time. A dull elementwise comparison with two loops in a C-Mex function is 3 to 15 times faster, see e.g. http://www.mathworks.com/matlabcentral/fileexchange/24380-cstrainbp. Even the simple M-implementation is faster than the original Matlab functions. Only if the number of elements exceeds a limit of about 500, the sorting and binary search is faster.
0 Kommentare
Siehe auch
Kategorien
Mehr zu Matrix Indexing finden Sie in Help Center und File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!