Why does union transpose row vectors when unioned with empty vectors?
6 次查看(过去 30 天)
显示 更早的评论
In R2013a, when you do union([],[1 2]) , MATLAB returns a column vector, i.e. [1;2], as opposed to the row vector [1 2] that it returned in prior versions. It is given in the documentation that the index vectors returned by union will now always be column vectors. However, that row vector will now be transposed whenever unioned with a null vector seems like it couldn't possible have a purpose, and at the least should be documented if it was intentional.
0 个评论
采纳的回答
Walter Roberson
2013-8-21
Look at
help union
You will find
The behavior of union has changed. This includes:
- occurrence of indices in IA and IB switched from last to first
- orientation of vector C
- IA and IB will always be column index vectors
- tighter restrictions on combinations of classes
So the change in orientation of the union output is documented.
2 个评论
Walter Roberson
2013-8-21
When I use union(), I seldom expect that the output will be the same as the input, as the input is allowed to be unsorted and with duplicates, and the order of the output is not specified by union() other than that it will not have duplicates (in practice it is also sorted.)
更多回答(1 个)
Jaron Kurk
2017-10-2
I agree with Mike. I just stumbled on this feature, which is, in my eyes, a design flaw, if not a bug, even if documented. This behavior is almost not deterministic, and I have to implement an extra check on emptiness or transpose vectors back and forth to handle this problem. That makes at least one user having additional work due to this unexpected behavior. Can anyone think of an example showing an advantage of this behavior (other than possibly simpler internals of the union function)?
1 个评论
Jan
2017-10-2
编辑:Jan
2017-10-2
If the 'rows' flag is not specified, then C is a column vector
unless both A and B are row vectors.
I admit that I cannot remember this securely. I do not like to read the documentation of such basic commands each time I use a function. That the behavior was subject to changes and cause incompatibilities between Matlab versions is a drawback for my work.
Therefore I decided not to rely on the orientation of the outputs of the set functions unique, union, setdiff, intersect, ismember anymore but shape the output to the wanted orientation in every case. A (:) is very fast and the transposition of vectors also.
Matlab tries to be very convenient with
- operating on the first non-singelton dimension:
X = rand(3,4); y = sum(X) instead of: y = sum(X, 1)
- the non-functional form of commands:
save File A instead of: save('File.mat', 'A')
The interpretation of the inputs changes with the Matlab version:
fullfile * * % Works in R2009a as: fullfile('*', '*');
fullfile * p % Fails in R2009a: '*' assumed to be a multiplication
Both worked in earlier and perhaps later versions.
- Using the current figure or axes:
plot(t, x) instead of:
FigH = figure;
AxesH = ('Parent', FigH);
plot(t, x, 'Parent', AxesH);
- Create square matrix for 1 input:
x = rand(2) instead of: x = rand(2,2)
- And for the set functions, guessing the wanted orientation of the output. What is the shape C = A(B), when A and B are n-dim arrays? This is exactly defined, but not trivial.
Such conveniences saves some key clicks for short hacks in the command window. But in productive code they are sources for bugs or confusions. You cannot blame Matlab for replying column or row vectors, because you can always find an example, where the other orientation seems to be more logical. For a reliable code, such details must be checked and adjusted manually, although this is tedious.
Being lazy is fine in Matlab. I type "profile on" in the command line also. But in productive code it is worth to add the additional keyboard clicks for (' and '). 0.5 sec longer for programming, 1 hour saved for debugging.
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Logical 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!