Deactivation switch for implicit expansion

Question

Matt J 2016-12-29

3
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/318495-deactivation-switch-for-implicit-expansion

评论： Digital Guy 2021-9-28

采纳的回答： John D'Errico

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

4 个评论
显示 2更早的评论隐藏 2更早的评论

Matt J 2019-1-7

编辑：Matt J 2019-1-7

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 2019-1-7

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 2018-2-20

3
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/318495-deactivation-switch-for-implicit-expansion#answer_306122

编辑：John D'Errico 2018-2-20

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.

7 个评论
显示 5更早的评论隐藏 5更早的评论

John D'Errico 2018-2-27

编辑：John D'Errico 2018-2-27

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 2019-1-5

编辑：Zhe Li 2019-1-5

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 2019-4-29

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.

Digital Guy 2021-9-28