Deactivation switch for implicit expansion

Does anyone know if there is a way to disable the implicit expansion feature introduced in R2016b?

[Star Strider]

What parts of MATLAB would you not miss?

[Matt J]

kaare commented:

I would love that as well.

[Matt J]

Just to be clear, I was asking about this purely as a debugging tool. I am in favor of implicit expansion as a feature and hope it's here to stay.

[Jan]

Maybe running the code and exhaustive unit-tests in R2016a is the best option for debugging. It will not only reveal implicit expansion problems, but all other incompatibilities with older software also. Unfortunately this requires a conservative programming style, e.g. to avoid modern strings defined with double quotes.

Answer 1

[John D'Errico]

I believe it is not possible to disable the expansion. Personally, I like having it, just that people don't like change. There is some risk in implicit expansion, in that MATLAB novices will sometimes get hurt.

Now, could they introduce a settable flag, telling MATLAB to not use expansion? Yes, they surely could do so. The problem is then code written is no longer portable. Move your code to another computer that has the flag set off or on, and suddenly your code will not work. Or if your code sets the flag and someone uses your code, then suddenly you may have effectively introduced a bug into their code.

So, sorry but IMO, a flag or preference that can disable expansion is a bad idea.

Could you disable it yourself? I suppose you could overload the affected operators, checking for any case of implicit expansion. If you find it, then trap out with an error, saying that implicit expansion is just wrong in your humble opinion, and you won't allow it to work on your system. If no expansion is detected, then use the built-in operator. Yes, it will slow down your code. But it would work.

[Walter Roberson]

John, I remind you that the %#ok flags already exist and affect only one line or only one file. There is no reason why similar flags could not be developed that are scoped at the file or function or line level.

[Matt J]

Could you disable it yourself? I suppose you could overload the affected operators, checking for any case of implicit expansion.

I attempted overloading bsxfun, hoping that implicit expansion expressions are all handled through that. Didn't work, unfortunately.

The problem is then code written is no longer portable.

The error message could warn that implicit expansion is disabled. In any case, I think a very similar risk has already been incurred. Namely, code that uses implicit expansion is not portable to pre-2016b Matlab installations that pre-date it. This is a little different than code that fails due to a missing function not available in an older version of Matlab. Normally, the error message would warn that the function call is unrecognized, but in the case of implicit expansion there is no clue as to why a simple matrix arithmetic expression fails to work.

[Steven Lord]

If you want to guard against implicit expansion, you could use the verLessThan function to determine if you're running in a release prior to release R2016b (which is when implicit expansion was introduced) or a release with implicit expansion and perform the operations appropriately.

[John D'Errico]

Yes. I'll admit that you could handle this as an editor level flag. But the example Walter gives, which is the %#ok flag to disable an mlint warning, is different from a flag which would change how the parser parses that line of code.

Regardless, while you COULD in theory disable expansion for a specific line using an editor flag, that requires you to know you don't want expansion to happen on that specific line. But if you know enough to decide to prevent expansion on one line, then you should know if there was any reason to expect an expansion anyway on that line. So an mlint style flag helps only those people who don't need the help.

I would argue that the reason why people MIGHT want to prevent implicit expansion is that expansion could introduce bugs into code written by novice programmers, because it surprises them. So an editor level flag that is specific to one line is useless for those individuals.

The flag I was talking about would be at the preference level, where you would completely disable implicit expansion for all code. Of course the problem with that is it will also disable implicit expansion in code provided in toolboxes and by TMW in MATLAB itself. It also makes code non-portable, a bad thing. I suppose one might argue for a preference level flag, that would disable implicit expansion ONLY in code written by the user, while allowing it to work in TMW provided code. That would seem difficult to implement, as well as confusing for the novice who looks at TMW provided code and does not understand how it works, nor could they even emulate the code if they have expansion shut down in a preference.

Finally, as far as portability into pre-2016 releases is concerned, that is something I think we cannot worry too much about. Every time ANY change to the MATLAB language is made, code produced is no longer portable to older releases.

You can argue about the importance of backwards facing portability versus forward portability anyway. In the case of forward facing portability, code that failed with an error in pre-expansion days will now work.

But my concern about portability is more for sharing code between colleagues, all of whom may even have the same release. There are many groups of individuals who use shared code as a resource among work groups. We had this all over at Eastman Kodak. Students do this. Researchers at universities, etc. Here you can easily have two people with different opinions as to how to set a flag that disables expansion. And this is where the concept of portability is IMHO, most valuable.

[Zhe Li]

I do not understand the logic behind John's answer. He is obviously overthinking it. Not everybody thinks about sharing their code or portability when they start writing codes. Many people use MATLAB for their own projects and never intend other people to read their codes. That being said, I believe this does not even necessarily introduce any problems when it comes to sharing code, if implemented "correctly", for example, if a script/function explicitly disables the expansion, dimension check is enforced only within the file. This could work like those options in g++ compiler -- although I admit I am not aware that MATLAB has done something like this before.

I just spent half an hour debugging my program (that ran through but produced wrong results), checking everything and eventually realized that I was using .* on a 1x10000 matrix and a 10000x1 matrix. It would have thrown an error in previous versions, which would allow me to fix this within seconds and give me correct results, when I know I absolutely do not need any implicit expansion in this program. How I wish I could do that.

You might think I am a "novice" programmer, as some have repeated used the word in their responses, but I have to tell you that I have used MATLAB for quite a few years and written tens of thousands of code, and errors like this can be buried pretty deeply, especially after a few matrix operations or after data are passed to another function.

I have got to say some people on the forum seem to worry about too much, like how "novices" will get confused blah blah. People only get confused when you do not explain it very well, right? And let us not talk about compatibility between versions -- anybody who has worked across several versions of MATLAB knows that it is a headache, and one should just be prepared to review all the codes every two years or so.

[Chuck37]

I just recently moved up to 2016B and implicit expansion is a nightmare. I write quick and dirty code for analysis and am getting burned by this. I'm not a "novice" at MATLAB by any stretch, but I have become accustomed to letting error messages guide me on trivial row vs. column situtations. I just spent an hour figuring out why I was getting the wrong answer from norm(a-b). It turns out, of course, that matlab was blowing a row/column mismatch out into a matrix. Ugh.

[Donald Guy]

https://uk.mathworks.com/matlabcentral/answers/318495-deactivation-switch-for-implicit-expansion#comment_657111

https://uk.mathworks.com/matlabcentral/answers/318495-deactivation-switch-for-implicit-expansion#comment_699667

These comments are spot-on, and exactly what I have encountered from my viewpoint as another "novice" who has used Matlab for >20 years.

Answer 2

[Jan]

I'm convinced, that there is no switch to disable it. Otherwise it would have been mentioned in the forum.

[Matt J]

Well, perhaps we can hope that one will be introduced.

[Sean de Wolski]

I wouldn't hold my breath.

[Matt J]

Maybe a better alternative would be a new flag in DBSTOP, e.g.,

 >> dbstop if implicit expansion

to intercept cases where implicit expansion was not intended.

[Jan]

@Matt J: A very good idea. +1. I've found another thread, where I can provide the vote for this comment :-)

[KL]

Does using dbstop work? I get an error.

[Walter Roberson]

dbstop is a proposal not something implemented

[KL]

Aha okay!