{"id":2084,"date":"2016-11-10T09:57:58","date_gmt":"2016-11-10T14:57:58","guid":{"rendered":"https:\/\/blogs.mathworks.com\/loren\/?p=2084"},"modified":"2016-11-08T08:32:55","modified_gmt":"2016-11-08T13:32:55","slug":"more_thoughts_about_implicit_expansion","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/loren\/2016\/11\/10\/more_thoughts_about_implicit_expansion\/","title":{"rendered":"More thoughts about implicit expansion"},"content":{"rendered":"

More thoughts about implicit expansion<\/h3>

Steve Eddins returns with another thoughtful post on implicit expansion.<\/p>

Several people have expressed some trepidation about the increased possibility of making an undetected error because of the introduction of implicit expansion in MATLAB R2016b<\/a>.<\/p>

Usually, people are worried about trying to perform element-wise addition of two same-length vectors, a<\/tt> and b<\/tt>, without realizing that one is a row vector and the other is a column vector. MATLAB R2016b will produce a matrix, whereas earlier versions of MATLAB produced an error. The concern is that a user might not realize that the computation wasn't what they intended, or that a user might run out of memory if a<\/tt> and b<\/tt> are really long.<\/p>

People expressing this concern sometimes suggest adding some kind of warning for the case of adding a row vector and a column vector.<\/p>

This is a legitimate concern, and it is one that was discussed a number of times during the years that implicit expansion was under consideration.<\/p>

We have a couple of reasons for thinking that this kind of unintended computation won't be a significant problem in practice. First, we don't think it is likely that the unintended computation will go unnoticed. For an interactive computation in the command window, it will be immediately obvious that the computation produced a matrix instead of a vector. For code in a script or function, if subsequent code is expecting an N-element vector, then something will likely error or be noticeably different if it gets an NxN matrix instead. Compared to typing *<\/tt> when you meant .*<\/tt>, or '<\/tt> instead of .'<\/tt>, an implicit expansion error with vectors is more readily identifiable.<\/p>

The second reason is that we haven't seen this issue crop up as a significant problem in our internal experience at MathWorks. Internal development builds of MATLAB have used implicit expansion since October 2015. We have seen that people typically get quickly accustomed to the new behavior. They start using it and stop overthinking it.<\/p>

Also, we don't think that running out of memory will be a big problem. For the past several releases, MATLAB has had a user-settable upper limit on the number of elements in an array. The limit is intended to prevent trying to make an array so large that your computer grinds to a swapping-induced halt. The introduction of this feature significantly influenced our final decision to go ahead with implicit expansion.<\/p>

The idea of introducing a warning message turns out to be infeasible, for a few reasons. First, there's not really a good way for MATLAB to determine whether or not you meant to get a matrix if you typed row + col<\/tt>. A pairwise summation of two vectors, which you might think of as an outer sum, is actually one of the common computational patterns that bsxfun<\/tt> was used for. So any warning message will probably appear at times when the arithmetic operators are being used correctly and as intended.<\/p>

MATLAB users are understandably not tolerant of code that produces warning messages when used correctly, so anybody writing mathematical code that might do implicit expansion would need to write extra code to save the warning state, suppress the warning message, and then restore the warning state. That's a lot of slow-executing machinery to be wrapping around simple matrix arithmetic.<\/p>

Also, warning-generating logic severely interferes with our ability to generate super-fast mathematical computations that fully exploit optimized processor instruction sets, instruction pipelining, and multiple cores. Adding warning logic to the implementations of basic MATLAB arithmetic would result in unacceptable slow-downs.<\/p>

These are some of the same reasons that the MATLAB Math team has actually removed some warning messages in recent years. The best-known example is the old division-by-zero warning that MATLAB no longer produces.<\/p>

To summarize, although we acknowledge that implicit expansion behavior may cause confusion in some circumstances, we believe based on our experiences that it will not be a big problem. Our observations of the use of repmat<\/tt> and bsxfun<\/tt> over the years led us to conclude that, on balance, the benefits of implicit expansion will significantly outweight the disadvantages. And finally, we think that a warning message of some kind is neither feasible nor desirable.<\/p>