MATLAB Answers

Should Implicit Expansion be Applied to Additional Functions?

2 views (last 30 days)
Paul
Paul on 9 Oct 2020
Commented: Paul on 11 Oct 2020
I know that some don't like implicit expansion. Given that it's likely here to stay, should it be made applicable to some additional functions? Just the other day I ran into a case like this, where one of X or Y is n x 3 and the other 1 x 3.
Z = X + Y;
Z = X - Y;
Z = dot(X,Y,2); % doesn't work
Is there some fundamental reason why dot can't support implicit expansion? If not, should it? Are there other functions, like cross, that should support implicit expansion?
Intresting to me is that the doc says: "Most binary (two-input) operators and functions in MATLAB® support numeric arrays that have compatible sizes. Two inputs have compatible sizes if, for every dimension, the dimension sizes of the inputs are either the same or one of them is 1." So most binary functions, but not all, support it. It would be nice if the doc had a single list of functions that support implicit expansion, or, if shorter, a list of binary functions that do not.

  13 Comments

Paul
Paul on 11 Oct 2020
Exactly. The discussion here is about implicit expansion. So for this example where we want to dot across the second dimension, as in the original question, we must have a 1 x 3 and an n x 3. Currently dot, cross, and others(?) reject this pair of inputs. So the question in this comment thread is: should dot, cross, and others be upgraded to accept these inputs and apply implicit expansion? Yes, I can implement this myself, and I have, but that’s not really relevant to the discussion, unless your position is that because I can roll my own version there is no need for TMW to modify theirs.
Bjorn Gustavsson
Bjorn Gustavsson on 11 Oct 2020
Yes, "roll your own" is my opinion on this, whenever I've had these cases I've either handled it such that I know which sizes the input-arrays can have and used matrix-vector multiplication, or for cross-products explicit expressions for the cases. Since it is a couple of lines and with operations matlab is supposed to excell at I dont see the gain.
Paul
Paul on 11 Oct 2020
That argument could be used against any use case, in the sense that we all were able to work before implicit expansion came into being.
So, is that your opinion just for dot? Or do you think that implicit expansion is not needed for any functions for which it is not currently supported? Or maybe there are additional functions that don’t support it now, but you think they should? If the latter, what are those functions?

Sign in to comment.

Answers (2)

Walter Roberson
Walter Roberson on 9 Oct 2020
Yes, it should be extended to datetime() objects.
>> datetime() + hours(1:5).' + hours(1:3)
Data inputs must be the same size, or any of them can be a scalar.
>> hours(1:5).' + hours(1:3) + datetime()
ans =
5×3 datetime array
09-Oct-2020 19:05:40 09-Oct-2020 20:05:40 09-Oct-2020 21:05:40
09-Oct-2020 20:05:40 09-Oct-2020 21:05:40 09-Oct-2020 22:05:40
09-Oct-2020 21:05:40 09-Oct-2020 22:05:40 09-Oct-2020 23:05:40
09-Oct-2020 22:05:40 09-Oct-2020 23:05:40 10-Oct-2020 00:05:40
09-Oct-2020 23:05:40 10-Oct-2020 00:05:40 10-Oct-2020 01:05:40
>> bsxfun(@plus,(datetime() + hours(1:5)).', hours(1:3))
Error using bsxfun
Operands must be numeric arrays.

  6 Comments

Show 3 older comments
Steven Lord
Steven Lord on 9 Oct 2020
Yes, implicit expansion behavior was added to several operators and functions on datetime, duration, and/or calendarDuration in release R2020b.
Paul
Paul on 10 Oct 2020
Does the doc have a list of binary operators/functions that support implicit expansion, with notes on exeptions? By exceptions I mean as in Walter's original exmaple, i.e., the plus operator supports implicit expansion except when the operands are a datetime and a duration. If it does, I couldn't find it.

Sign in to comment.


Matt J
Matt J on 10 Oct 2020
I wouldn't mind seeing it extended to the colon operator, instead of having to do things like this,
a=2;
b=[5,7,9];
c=arrayfun(@(q)a:q, b,'uni',0); %I'd rather just do a:b
c{:}
ans = 1×4
2 3 4 5
ans = 1×6
2 3 4 5 6 7
ans = 1×8
2 3 4 5 6 7 8 9

  8 Comments

Show 5 older comments
Matt J
Matt J on 11 Oct 2020
I don't think I have ever seen a good reason to permit non-scalars in the colon operator.
I suppose I was really thinking that it might be good if combined with automatic comma separated list expansion. So, for example, instead of extracting a sub-array given its lower and upper limit vectors a and b,
M(a(1):2:b(1),a(2):2:b(2),a(3):2:b(3))
I could instead just do,
M(a:2:b)
Steven Lord
Steven Lord on 11 Oct 2020
I'm not completely certain, but I suspect Bruno Luong's answer is close to the mark. The colon operator dates back to a very early version of MATLAB, probably even Cleve's original Fortran MATLAB. I suspect Cleve didn't consider that people would use : with non-scalar values and so didn't check for that.
We've learned since then. Were we to redesign : today, we likely wouldn't allow non-scalar inputs without a good use case.
Matt J
Matt J on 11 Oct 2020
We've learned since then. Were we to redesign : today, we likely wouldn't allow non-scalar inputs without a good use case.
In addition to the one I raised above, I think that a good case would in the use of griddedInterpolant. Instead of upsampling an array V by doing,
F=griddedInterpolant(V);
[m,n,p]=size(V);
Vq=F({1:0.5:m,1:0.5:n,1:0.5:p})
it would be much more sleek to do,
Vq=F({1:0.5:size(V)})

Sign in to comment.

Products


Release

R2019a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!