Deactivation switch for implicit expansion
显示 更早的评论
4 个评论
Matt J
2018-2-21
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.
采纳的回答
John D'Errico
2018-2-20
编辑：John D'Errico
2018-2-20
3 个投票
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 个评论
Walter Roberson
2018-2-20
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.
Steven Lord
2018-2-21
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
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.
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
These comments are spot-on, and exactly what I have encountered from my viewpoint as another "novice" who has used Matlab for >20 years.
更多回答（1 个）
Jan
2018-2-19
1 个投票
I'm convinced, that there is no switch to disable it. Otherwise it would have been mentioned in the forum.
7 个评论
Matt J
2018-2-20
Sean de Wolski
2018-2-21
I wouldn't hold my breath.
Matt J
2018-2-25
Jan
2018-2-26
@Matt J: A very good idea. +1. I've found another thread, where I can provide the vote for this comment :-)
KL
2018-2-27
Does using dbstop work? I get an error.
Walter Roberson
2018-2-27
dbstop is a proposal not something implemented
KL
2018-2-27
Aha okay!
类别
在 帮助中心 和 File Exchange 中查找有关 Matrix Indexing 的更多信息
产品
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
