General
Follow


Alessandro

Are the rules for element by element matrix operation changed?

Alessandro on 13 Mar 2024
Latest activity Reply by Dyuman Joshi on 16 Mar 2024

Hi
I have Matlab 2015b installed and if I try:
ones(2,3,4)+ones(2,3)
of course I get an error. But my student has R2023b installed and she gets a 2x3x4 matrix as a result, with all elements = 2.
How is it possible?
Thanks
A
Dyuman Joshi
Dyuman Joshi on 16 Mar 2024
Why was this post transferred from Answers?
David Young
David Young on 14 Mar 2024
I'll just add that the introduction of singleton dimension expansion made me very happy. I'm still a bit pleased when I can replace bsxfun or repmat somewhere.
If it's a problem for students learning the language, then so will be broadcasting in Python and other languages. It's arguably better for students to learn early on of this convention.
John D'Errico
John D'Errico on 13 Mar 2024
Long ago, in a galaxy far, far away, we all used to use repmat to work with arrays of different sizes like that. Our code was good, and was blessed by the gods of MATLAB.
Then a good wizard named Loren helped us, providing us with the function bsxfun. It too was seen to be a good thing. But after some years of using bsxfun, the gods of MATLAB provided us with singleton dimension expansion. This happened with release R2016b. We all reveled in the beauty of our new tool, though even today some still lament the problems it creates. (Usually for new users, who are seen to be creating accidentally immense arrays.)
Now we can do things like this:
A = (0:4)' + (1:4)
A = 5×4
1 2 3 4 2 3 4 5 3 4 5 6 4 5 6 7 5 6 7 8
which is a true boon for those of us who desire an addition table. ;-)
Seriously the ability to expand singleton dimensions when performing operations like that makes our code often much simpler and far more easy to read. The bsxfun and repmat solutions always felt like just something we needed to accept, but they never felt like something truly pretty in my eyes.
Alessandro
Alessandro on 13 Mar 2024 (Edited on 13 Mar 2024)
I don't think I could express myself better than Petr Krysl in his reply on the blog post (link in the first answer). So I stop trying to explain why this is not an improvement after all (my opinion, of course).
But when you say "A difference is that some code which produced an error then...", well: errors are parts of life, and are a necessary step for learning. I teach a bit of MC coding in my class using MATLAB, and trust me: students may try to sum, subtract of multiplying things without having a clear idea of what they are actually doing. Now my students have more troubles in understaning their mistakes, just that. And I think also Mathworks has some problems in understanding its mistakes. Not sure about the dinosaurs.
John D'Errico
John D'Errico on 13 Mar 2024
"In my opinion this change of behaviour is unacceptable, because it breaks the compatibility."
I'm sorry, but no. Changes must happen over time in any language that has persisted for something like 40 years now. Sometimes changes must happen, and this change is one that was discussed at great depth.
Before bsxfun was introduced, there was a great deal of discussion on the topic. (I was involved in those discussions.) In fact, I even recall the idea of singleton expansion floated as an alternative, and at the time, it was voted down. I imagine after a few years, bsxfun was also found to have issues, and singleton expansion popped back to the top, as a better alternative.
The fact is, nobody will ever be happy with every change out there. As humans, we should be able to adapt to change.
Anyway, does this break compatibility? Arguably, NO. Valid code along these lines in a past release that did work pre-R2016b, will still work. A difference is that some code which produced an error then, now now longer produces an error. Such is life. This just means you need to update your own teaching to reflect a change that was made. Sorry. We must be able to adapt, or we all go the way of the dinosaurs.
Alessandro
Alessandro on 13 Mar 2024
Of course it's too late to ask for Mathworks to change it back. I think that the fact you discussed that a lot at least demonstrates that there were a lot of potential drawbacks.
I would like to espress my extreme frustration so that similar decision may not be repeated. Maybe I'm 8 years late, but better late than never.
In my opinion, this improvement just makes the code a little shorter. In the most frequent cases like: size(A)=[2,2], size(B)=[2,1], you can now write
A+B
instead of
A+B*ones(1,2)
At the cost of clarity, because the second line is actually what you should "think" of. A shorter code is not necessarily better. (Multidimensional arrays requires more coding, but I think you got my point.)
Speaking of introducing new functionalities, honestly I think your point is not strong. This way to introduce new functionalities is the things that made me migrating from IDL to MATLAB. bsxfun is a new functionality, this is just risky, and saves some time for lazy coders.
Just think about introducing a further step, that MATLAB can also handle incompatible sizes when there is only one possible logical expansion (i.e., you can do ones(7,3,5)+ones(7,5); there is just one possible expansion, so that in principle a future MATLAB release can handle this as well).
It's obvioulsy something extremely dangerous to do.
My functions and scritps (see below) rely on the assumption that this sort of "improvements" would have not been possible, and now my trust in this product is quite diminished.
Regarding the blog post, I'm having a lot of fun reading all the complaints to this decision at the bottom of the post. Too bad you closed the comments.
Alex
find . -type f -iname '*.m' | wc -l
14952
Steven Lord
Steven Lord on 13 Mar 2024
In my opinion this change of behaviour is unacceptable, because it breaks the compatibility.
If you take that position strictly, then we can never add any new functionality to any of our products.
  • Any new function that we add to MATLAB could conflict with the name of a function that a user has defined and so break their code.
  • Every single bug we fix could break a user's workflow (obligatory XKCD: 1172 (Workflow)).
  • Every single error message that we change in a release to make them clearer to understand, by your definition, would be an unacceptable incompatible change since "I need my students to have same errors for the same code."
  • Even speeding up a function could theoretically break user code that tried to use it in a real-time (or real-time-ish) application and depended on it taking at least X seconds to run!
We do take compatibility very seriously. But unless you want MATLAB to be frozen at its current state, never to introduce any new functionality or bug fixes, it must change at times.
There are changes that are likely very minor incompatibilities like the fix for Bug Report 2895504, where the sign function occasionally changed the bit pattern of a NaN input to a different NaN pattern, or just about any case where MATLAB crashes. [Hopefully no one is depending on MATLAB crashing when they do X like user LongtimeUser4 depended on CPU overheating in the XKCD comic!] These don't usually require a lot of discussion; fixing a crash is usually a no-brainer, and if I recall correctly fixing bug 2895504 wasn't that controversial.
On the other hand there are changes that have the potential to be much bigger deals (like implicit array expansion.) Trust me, we discuss / argue / negotiate about larger potentially backwards incompatible changes a lot. In particular, we (I participated directly) had a lot of discussion internally about this incompatible change when it was introduced.
As stated in the blog post linked in the accepted answer, "This change to MATLAB arithmetic was not without controversy at MathWorks. Some people were concerned that users might have written code that somehow depended on these operators producing an error in some cases. But after examining our own code base, and after previewing the change in both the R2016a and R2016b Prereleases, we did not see significant compatibility issues arise in practice."
James Tursa
James Tursa on 13 Mar 2024
"... this change of behaviour is unacceptable ..."
That ship has sailed. There was much discussion on both sides at the time implicit array expansion was implemented, but what's done is done and I doubt MATLAB is going to reverse this decision. Every language is going to have its own idiosyncracies, and this is one of them for MATLAB. The pagemtimes() function behaves this way also ... it is not limited to the element-wise functions. Personally, I love it as opposed to the klunky bsxfun, and I wish other languages behaved this way also.
"... I need my students to have same errors for the same code ..."
That is something you will never be able to guarantee for different versions of MATLAB. E.g., simple bug fixes would break this paradigm. I would suggest you simply point out this behavior to your students and leave it at that.
Alessandro
Alessandro on 13 Mar 2024
Thank you for the funny novel. Let's focus on the serious part.
In my opinion this change of behaviour is unacceptable, because it breaks the compatibility. Even errors need some compatibility: I need my students to have same errors for the same code. And personally I think that this may lead to a lot of physical bugs, because sometimes one does not really want to perform expansion, but fails to realize it's done by MATLAB.
Voss
Voss on 13 Mar 2024

See Also