Are there parts of MATLAB that could disappear as far as you were concerned, things you don't need or which were "bad ideas" or which cause more trouble than they are worth in your experience?
One suggestion per answer please, so we can see how other people feel about the same matters.
94 Comments
Tim Harmon: Depending on your license and what you need to use MATLAB to do, this may be possible. See MATLAB Online.
Installing MatLab
\
Admin permission required to install python API. No other python modules I have ever used require this:
https://www.mathworks.com/help/matlab/matlab_external/install-the-matlab-engine-for-python.html?s_tid=srchtitle
Now that I've been forced into Linux at work, I wouldn't miss ls for a minute. It behaves horribly compared to in Windows, and means my code is not cross platform.
I've spent the last 2 days replacing every instance with
a = dir();
a = {a.name}';
Commenting on another answer just reminded me of something else:
eval(...)
Ok, I'll be honest. There's that one time I just couldn't do anything else, but I hate myself everyday for caving into eval. I would miss it just a little bit, but I would actually feel better if it was gone.
Since R2022a str2num provides a switch to only allow basic operations. It should have been the default, but suddenly there is a way to use str2num without opening a gaping hole in your program:
str2num('[1 2;3 4]',Evaluation='restricted')
str2num('disp("I''m a trickster!")',Evaluation='restricted')
There is a niche of programs intended to graph (or do root solving) of user-supplied equations. Some of those are just homework assignments, but some of them are serious tutorial work or convenience graphics calculators.
In those cases, it can be difficult to resist using eval(). str2func() does help but it does not always work, and when I use it I still feel nausea to some extent as I know that I haven't done the slightest thing to prevent the security risks.
There is need for a "sandbox" function that can evaluate untrusted code (especially given as string) in a safe environment that does not allow file output and only allows file input of files the caller of sandbox specifically injects into the sandbox (which, sigh, people would tend to do without verification of trust.)
And now for my own "wouldn't miss it" feature:
finish.m
I have never used it, have never considered using it or thought it might be a solution to my problem, and haven't heard of a good use for it. Except the one guy that used it in some coworker-trolling code.
Honestly, ability to use old releases is almost on my list of wish it wasn't possible.
I know R2007a was a popular "cracked" version, haven't heard anything since then, but haven't researched it either.
I can imagine professors insisting on old releases because they don't include some of the new features that make the assignment completely trivial. A lot of my coursework included "do not use the built-in [function_name], write your own." A release that doesn't include said built-in makes it a lot easier on the professor.
These days I seem to be regularly advising people who turn out to be using 2010a or 2011b or 2012a or 2012b or 2013b, sometimes 2008a or sometimes even R13. The requests seem to clump together, with the completely obsolete versions not getting mentioned for a while and then suddenly it is almost as if some university class has required that students use something old.
To be honest, sometimes I wonder if those old version numbers correspond to popular cracks, if that is the reason why more people than one might expect show up using the old versions. And yes, that includes in assignments from professors (that is, I do get the impression some times that some professors are using old cracked versions and that is the reason why they insist that students use something so obsolete.)
As to question 95875, that was fixed in R2014b.
To the others - fair enough; not something I've needed to do yet.
I seem to recall another use as well. Perhaps something along the line of forcing a connection to shut down, as some kinds of resource reservation persist past the program shutting down. For example if you are using ActiveX to talk to a shared server then the server doesn't know that your program has disappeared and that it needs to do (whatever).
Matlab 6.5 crashed, when it was stopped by exit during an audioplayer object is existing. Therefore I added a function in finish.m, which clears all of my functions calling audioplayer. In addition a backup of all modified M-files is triggered.
@Greg — Thank you for reviving this thread. I didn’t know it existed.
For me, it would be ‘automatic array expansion’, introduced (if I remember correctly) in R2016b.
Can’t everyone just learn to use bsxfun? It’s not that difficult!
@Star Strider has it exacly right. In fact, implicit expansion is why I stopped using Matlab in favor of Julia. Matlab is a tool and tools should save me time, but starting in 2017 this fundamentally changed. Implicit expansion, as implemented, was costing me far more time than it ever saved, in similar ways to https://www.mathworks.com/matlabcentral/answers/383533-how-do-i-avoid-getting-fooled-by-implicit-expansion.
Julia just makes implicit expansion pedantic, and it works far better in terms of time spent writing code vs. hunting down accidental dimension mistakes. @Stephen Cobeldick offers some good ideas for how to fix this.
I periodically check back in with Matlab to see if this has been fixed, but alas as @J. Alex Lee points out there is not much active discussion on this point.
so does anyone know why, in the end, it was decided that silently implict syntax for implicit expansion was a better idea than introducing an explicit syntax along the lines of what Stephen said above with different types of binary operators (actually i dont even know what expanding matrix ops means)?
I embraced implicit expansion because for whatever reason I couldn't keep bsxfun syntax straight in my mind, but now I'm being bitten enough by it with inadvertent usage that I've been driven to seek blogs and discussion about this design decision...can't find much since some flurry of activity in 2016 upon introduction and some discussion in 2018...
@Greg: Unfortunately the implicit expansion is sometimes substantially slower than bsxfun.
@Stephen: I agree that these different operators would be useful to avoid bugs. Currently a line of code, which relies on implicit expansion is only clear and clean, if you add a comment, that this is intended.
It would be nice to have four different kinds of binary operator (and transpose):
- strict element-wise
- expanding element-wise
- strict matrix operations
- expanding matrix operations
I came up with a reasonable syntax, but it is not compatible with MATLAB.
Other (recently developed) "scientific" languages that I have used/experimented with seem to be written by programmers for programmers: apparently any thoughts of real mathematics rules being applied was the last thing on their minds.
It's formally called implicit expansion, and it's amazing. Supposedly faster than bsxfun in most cases.
And you are welcome.
I stumbled across this question and thought it would be fun to revive it. A lot has changed, so I wonder how many are still "unmissable," might not be applicable anymore, or any new additions.
Class events. Does anybody actually use these?
The model for these in MATLAB is a little strange. For instance, listeners keep a reference to the object they are listening to, thereby preventing that object being destroyed. The reference is unnecessary given that events are a 'push' mechanism.
This makes the ObjectBeingDestroyed event defined on handle useless, becuase as soon as you listen for it, you prevent the event from ever firing! (Barring evil explicit calls to delete.) It's the ol' watched kettle that never boils.
Class events are awesome. As for listeners keep references, that's precisely the difference between handle.listener and handle.addlistener. You get to choose whether the source holds the reference or the listener holds the reference.
I use them and don't want to be without. However, I cannot say whether the implementation in Matlab is the best.
We do not need deterministic finalisation for reference types, especially when they form part of a reference cycle. More simply put, we don't need MATLAB to go to great lengths to guarantee it will call the delete method on (and free the memory of) objects the very instant that they are no longer used.
The fact that MATLAB has this feature is apparently the cause of performance-sapping overhead. Case in point: it takes O(n) time to get or set a single element in a cell array if that array is a property of a reference-typed object. Try building an O(1) collection class with that restriction!
I'm not aware of any other runtime with managed memory that wastes time giving this guarantee. CPython uses reference-counting similar to MATLAB, but doesn't have deterministic finalisation for objects in a cycle. Java and .NET of course don't have deterministic finalisation for any objects!
The MATLAB language really would be better off though with support for a proper finally block instead.
My pick would be obsolete tools like gatool, which can now be accessed via optimtool.
I think we could do without one curious perversion of functions: a function where you don't pass a variable's value, but you pass the name of the variable instead! I'm lookin' at you, save():
save( 'foo.mat', 'x' );
The code analyzer now correctly picks up on these uses.
myVar = rand(10,1); % no linter warning
save('Test.mat','myVar');
Even the mass name replacements work.
My minify function is not yet updated to deal with this, so I'm still using tools like I described a year and a half ago.
I personally use a separate function to save variables to a mat file. It includes a timestamp and the name of the function that created it. It also makes sure Octave uses the Matlab format, and that Matlab 6.5 can read the files. Using this function I can actually use the tools to change all occurence of the variable names (and the linter doesn't complain anymore). 10 minutes to find inputname and 10 minute to implement the function. 20 minutes of my life that have probably saved me 5 years worth of life span by prevent blood pressure spikes.
I suspect that this is closely related to the origins of MATLAB: back when the height of programming sophistication was a glowing green monitor (80 characters wide) and the use of command syntax for everything. In that context save, load, etc make sense, because command syntax requires that the input must be interpreted as a literal string, and thus can only represent the variable name. Perhaps it was even considered good language design at the time?
Sadly we are now stuck with these strange remnants...
I agree with Walter here, but it is a painful lesson to learn the first 5 times. My problem with save is the Code Analyzer barking that a variable might be unused (or unset in the case of load).
myVar = rand(10,1); % 'myVar' may be unused
save('Test.mat','myVar'); <-- I use it right here Code Analyzer!
People *do* construct (compute) the name of the variable to save, and thus need to be able to pass a variable that contains a string but that variable is not itself the thing to be saved.
I wonder if they're worried about people doing stuff like save('foo.mat',@tan(x))?
They could easily implement a version that accepts variables in the usual manner. I could do it myself using inputname.
I think thats tough. save compares the names given to ones in the workspace, and saves them, I suppose.
I never used the "Start" Button which provides access to tools, demos, shortcuts, and documentation. I would be very curious to know if you are using it !!
I already asked this question on the "Mike on the MATLAB Desktop" blog: MATLAB User Survey (and maybe a free polo shirt) after answering their survey.
Not anymore. =)
There's a "Start" button?
I use it frequently to get to demos for various toolboxes. Sorry to rain on the parade...
I never use that either. Maybe it's designed for people who work on Windows machines, use the tools a lot or aren't old MATLAB users who are set in their ways.
I never use multi-row CHAR arrays.
"there is no obvious mechanism to cellstr() an sprintf() output"
Jan put me on to sprintfc() . Which, oddly, turns out to go across rows instead of down columns.
sprintfc('%d, %d, %d.', [[1;2], [3;4], [5;6]])
ans =
2×1 cell array
{'1, 3, 5.'}
{'2, 4, 6.'}
Yay for string data type! As soon as it is fully functional, I doubt I'll ever use char again.
I use them quite often... mostly for UI related things
I'm using a modified version of DEC2BIN, which assigns UINT8 arrays instead of a CHAR. This uses the half memory and the export to a Mex is more direct.
This is one that I do actually use, and which I think has a lot of internal uses. For example, dec2bin() applied to a vector produces a multi-row char array.
I create formatted output by horzcat'ing together blocks of text. Although that sometimes has relationships to things that could be done through appropriate sprintf(), the char array approach is faster -- and there is no obvious mechanism to cellstr() an sprintf() output (regex split is too much overhead for such a thing.)
I wish the MathWorks would not "dumb things down". This is especially apparent in the GUI development tools, but there are other examples also. Why are the powerful capabilities of the underlying java GUI objects hidden from the user? There is a whole market for utilizing this capability that drives websites like http://www.undocumentedmatlab.com/. People want/need to be able to access this functionality. Thanks to Yair Altman, I have been able to include some of the functionality that I need. But it is so painful (and questionable for future compatibility), the question of whether to use Matlab at all is difficult to justify with my peers.
I suspect that one of the concerns here is the complexity of supporting advanced functionality. I think that sometimes the need to support the basic user overshadows the needs of people who want everything a GUI has to offer. Most unfortunate.
quit
I would never miss that function because matlab is always open on my laptop :)
FYI in the Preferences for MATLAB, the General section has an item for Confirmation Dialogs. One of the dialogs you can enable (it isn't on by default) is "Confirm before exiting MATLAB".
I just got bit a few minutes ago, went to dbquit and accidentally quit instead, accidentally closing my session :(
Really? Cool (in the "I didn't know that" meaning, not the "that's an awesome way for it to behave" meaning).
Clicking the x on the desktop is not the equivalent to quit or exit: any GUI that has been opened on your behalf that uses internal figures (perhaps Java based) can survive being x'd. x'ing the desktop does not reliably close Simulink windows, for example.
Clicking the x in the MATLAB desktop (not the Editor or a running app, etc.) is equivalent to quit or exit.
Point taken for testing framework - I'm still working toward that.
Clicking the x in the corner only gets that one window, not all of the other windows one might have open.
But with respect to wanting to programmatically kill a MATLAB session: Running in an automated mode where you know the session is finished. Especially in a testing framework were you can't be sure of what got created or not.
I agree, quit and exit both seem pointless. Click the x in the corner - why in the world would you ever programmatically want to kill the MATLAB session?
Even when you're installing a new version?
It would be helpful, if a modification of the window icon will not conflicts with the license conditions.
When I open 120 Matlab figures, it can be helpful to group them optically in the popup-menu of the Windows-taskbar, e.g. by different colors in the icon.
Case-insensitive command recognition.
When I'm working on Linux, I have to consider the correct upper/lower case. The ability to call a command with a deviating case is a source of bugs and not a valuable freedom.
I appreciate, that case conflicts create a warning in modern Matlab versions.
@Steven: Thanks. I can't believe it was that long ago (I remember the time when it was a warning).
This now fully errors on Windows systems. I forget which release, but problem solved.
@Walter: I assume a missunderstanding.
If Mycommand and myCommand is defined, mycommand should and does fail. But currently "MEAN(1:2)" runs under Windows, but fails under Linux (is this still true with modern Matlab versions?). Since 2008b (or earlier) at least a warning appears on Windows when "MEAN" is called the first time. I think the inconsistent behaviour between Windows and Linux is not useful and a source of bugs. Fortunately TMW agrees and calling a function with the wrong case will become an error.
Jan,
Mycommand = @(x) x.^2;
myCommand = @(x) x.^3;
Now if the user asks for
mycommand(7)
then which should be invoked?
You can't get rid of case sensitivity for "commands" without getting rid of case sensitivity for variable names.
No. Just no. That some operative systems do not differentiate between upper/lower case might be handy, but to (suddenly) not do this in those OSes that do recognise the difference would be far worse.
That the colon operator and linspace produce slightly different answers. I know, I know, there reasons involving round-off when people innocently use step sizes such as 0.001, but 0:.01:100 not being the same as linspace(0,100,101) or (0:100)./100 {which come out the same as each other} is just asking for trouble.
Although it might mess the semantic model up a bit, it would not fluster me if the step size in a colon operator could be expressed as a rational whose rationality was recognized and used to create more precise steps -- e.g., 0:3/100:1 being interpreted as 3.*(0:100)./100.
I wouldn't miss colon being implemented through cumulative sums when it could be implemented by begin + (idx - 1) * step, which would at least _reduce_ the errors.
But in particular I wouldn't miss the countless questions that the current behaviour leads to. The current implementation is a mis-feature IMHO.
@Walter: I'm not sure this is an answer for this question. What exactly would you not miss if it went away? Colon operator?
I think this answer is more for this question:
http://www.mathworks.com/matlabcentral/answers/1427-what-frustrates-you-about-matlab
I personally would not miss GUIDE. Because I have to create programs which are compatible to Matlab 6.5, the compatibility limitations of GUIDE are too strong.
I use GUIDE sometimes to create the layout of a GUI. But then I create it programatically.
Still in R2020a, AppDesigner still has too many limitations for me to bother even starting with it.
I have to agree GUIDE is painful, and hurray for AppDesigner! With R2017b, it is almost ready to fully replace GUIDE.
GUIDE should rather just generate programmatic UI code.
GUIDE might be acceptable if it emitted code that was position-independent and auto-resizing by default. Something usable as a starting point for developing further code rather than something best suited for Bad Coding Practices Hall of Fame.
I've a lot experiences with creating GUIs programmatically now and I've a set of templates for standard tasks like: Open a dialog, load prefs, save prefs and windows position in the DeleteFcn. Therefore I will not use GUIDE even if it is improved. But most of all: For me, "improved" would mean a backward compatibility until Matlab 6.5... But this would exclude UITREE and UITAB from modern GUIs, what would not user-firendly. Therefore I've inserted "personally" in my answer - I do not expect that this opinion matchs the majority of Matlab users.
Just curious, do you want to completely do away with the interactive way of building GUIs, and do everything programmatically? Or you want a better GUIDE?
I agree, I wouldn't miss GUIDE either.
STRMATCH!
FIND(STRNCMP) is much faster.
@Jiro: Fine. Fine? Why not just implementing it more efficiently?! You can be sure, that there will be a fast STRMATCH in the FEX as soon as TMW removes the original function.
Your wish has been granted! As seen in the DOC, "strmatch" will be removed in a future release.
http://www.mathworks.com/help/matlab/ref/strmatch.html
For me, probably the easiest to identify would be the Java interface. Yep, I know the UI is implemented in Java, and that lots of tricky things can be done to extend Matlab functionality using the (ever-changing) Java interface, but personally I'd be happier if there was a clean break between the graphics and UI model and the underlying implementation so that the graphics could be replaced (with something faster and more flexible) without changing the programs. Diddling with things one can reach off of the Java frame is a hack unless you are going to whole-heartedly embrace Java as part of the programming model rather than as "private information" that the tricksters can manipulate.
Go ahead, try to convince me that Java is a big Win for Matlab. Who knows, maybe you will succeed.
java does turn out to underlay a lot of different functions including (for example) a lot of the Instrument Control Toolbox.
I have to say that in the years since I wrote the above, I have occasionally taken advantage of the java interface to call upon specialized libraries, such as reading from the middle of a gzip. But that use is in spirit no different than using the python interface or loadlibrary, and does not involve Java baked in to the graphics interface.
Another one it looks like they are working on. Can't wait to be completely rid of Java.
@Jiro: You are right. I limit my criticism about java to the graphics and GUI related functions.
I don't think I can convince you (but maybe others can), but what about using java in MATLAB for non-graphics related stuff. There are some nice network utilities that's rather hard to do with regular MATLAB. Here's an example I found in one of my files:
% Find out all the IP addresses for this computer
myComputer = java.net.InetAddress.getLocalHost;
allMyIps = java.net.InetAddress.getAllByName(myComputer.getHostName);
Correct! And the Java interface is still less readable as the old Windows methods in Matlab 6.5: E.g. in an edit UICONTROL with Arial in 10 pt the characters start directly at the left margin without a single pixel border. Ugly.
And GETFRAME captures the all elements of a figure after PAUSE(0.02) in 99.99% of the cases, so PAUSE(0.03) is "safer" in Matlab 2009a (and higher?). Strange.
The non-functional form of commands like "load file.mat" instead of "load('file.mat')".
mex is a case where the space-ends-argument of the command form would seem to be important to take into account. Not long ago I chased this far enough to see that it really was pasting together command line arguments with embedded spaces without enclosing them in quotation marks, and was counting on something downstream to be able to successfully guess which spaces were significant and which were not :(
cd 'C:\Program Files\MATLAB'
Works just fine. But at that point, you're so close to functional form, what's the point?
I do use the command form a lot for help.
I also use it for cd. On the other hand, for cd I keep running into the limitation that command form ends each argument at whitespace, so if I cd to a location that contains a space in a directory name using command mode then it does not work like I might otherwise hope.
Some convenience, but also a lot of confusion:
I'm with Jan on this one, definitely wouldn't miss it if it disappeared. I use doc textscan all the time, but wouldn't have a problem converting to doc('textscan').
hm, I would prefer having this around for 'cd' and 'dir'.
@Jiro: You got me: I admit I type "help plot" also. But the non-functional form is (and will be) still inconsistent. E.g. "fullfile * *" is ok in Matlab 2009a, but "fullfile * p" is not - but it was in earlier versions.
I sometimes like using the non-functional form when doing things from the command line. If I need to search the doc, I'd rather type:
docsearch functional form
than
docsearch('functional form')
I'm still faster at typing things that don't require using the shift key.
Heh, it was your earlier comment about this that inspired me to go ahead and make it a Question; it was going to be my second point.
See Also
Tags
You can also select a web site from the following list
Americas
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)
Asia Pacific
- Australia (English)
- India (English)
- New Zealand (English)
- 中国
- 日本Japanese (日本語)
- 한국Korean (한국어)