See also the main matlab page of this site, for parallel pages.
Most of the bugs cited here are to do with user-interaction, ease of use, figures, printing, and setup, rather than with any problem in the core routines or documentation. As various colleagues have remarked in different ways, "it's what you'd get if you got mathematicians to write software: good concise documentation, clever functions, etc., but sometimes ghastly user-interface". Note too that our use has been almost entirely of core matlab and a bit of simulink, rather than of the more exotic capabilities of stateflow, toolboxes, etc.
A strong usability drive, including mathworks employees using all supported OSs, and training these people to think always of "could this be annoying?", "could this be better(easier)", and "is this the expected behaviour within this OS, compared to other common applications?"
Now follows quite a list, if possible with original "Thread" codes, of big and little problems, some of them fixed (generally after several half-yearly releases) in case you're interested in some basis for my complaints. I'd be delighted if the new interest in improving the program does result in this sort of annoyance being removed.
[THREAD ID:1-147AUY] At least for early 7.x releases, mcc didn't work.
It
was necessary to include an extra option, since mcc was trying to link a C++
library from the C compiler. That the old behaviour of assuming the
necessary options, was going to stop had apparently been warned by GCC
developers for years, e.g. http://gcc.gnu.org/ml/gcc/2004-04/msg01041.html.
What really annoyed me here, when I reported the problem, was how it was
regarded as quite reaonable and natural that each user should have the
problem and search for a fix, rather than that matlab should just be changed
immediately to have the correct options added when calling gcc.
Using the uigetfile function in linux (unix generally, I assume) with the Multiselect option turned on, there are errors so that when selecting files the chooser ends up denying that they exist, even after showing them and letting them be selected. There's a "work-around" that one discovers a few hours later: setappdata(0,'UseNativeSystemDialogs',false). It would have been better to have fixed the problem or to have set the working chooser to be the default.
[Case ID: 1383734]. Switching keyboard layout (X11, linux) in earlier versions, 6.x, caused the entire Matlab GUI to crash. This took a while for me to identify as I often changed keyboard for an email then came back to a dead matlab session. It was only fixed in v7 from what I remember.
[THREAD ID:1-38300I] Subject: Hidden (dot) files.
Unix convention is that filenames starting with a dot are hidden in the shell
and in most file-managers. The home directory generally contains tens or
_hundreds_ of dot-files and directories of configuration for various
programs, e.g. matlab's own ~/.matlab/ directory. Matlab still starts by
default in ~/ (home) and has no way to avoid showing dot-files in
the "Current Directory" window. The "Current Directory" therefore has to be
scrolled several lengths just to see any of the useful files.
To avoid the problem, I always start matlab in another directory, but it would
be nice if it were to behave like pretty well any other program and hide hidden
files by default.
It's rather annoying that for example clicking on a figure file or m-file in the Current Directory sub-window while running some calculation in the command window, doesn't allow the requested action to be taken until the running command stops. It's surely possible to program matlab to allow the user to do other things with the desktop while something is running. That would be much more efficient with time. Indeed, a means of backgrounding a process, as in any unix shell, would be extremely handy. Forking new processes is easy...
A general annoyance: we have multi-CPU machines, and other programs e.g. Scilab using blas-atlas and lapack, can be compiled with support for SMP in matrix operations, which has often increased speed considerably. Matlab has no capability for SMP, but only for an add-on toolbox that splits tasks between processors (i.e. not useful for increasing speed of single data-intensive operations). Mathematica, I gather, has now good SMP support. We have many applications where increased speed is desired without there being an easy way to do primitive (distributed) splitting of isolated tasks: only proper SMP support will help. Addendum: there has been some such support, since about mid-2007
[THREAD ID:1-11SADO] Subject: Matlab 7 process interruption and waiting.
[THREAD ID:1-2UUX7G] Subject: Printing problem in new version.
[THREAD ID:1-158J5M] Subject: tilde (~) character on Swedish keyboard
(using X11 on linux).
[Service Request # 1-RVW3O]
(this was mentioned in the earlier email, but you
correctly point out that the latest release is not as severely bad).
Yes, I see this is the case. The behaviour I described is true for version
7.1 sp3 and some previous ones. But the "still awful" comment does apply to
R2006b:
Consider a "does what the user wants" program, e.g. Xfig (at least as
regards figure save and export). Save an (xfig) figure as "name.fig". If you
type just "name" it will show you that it's changing this to "name.fig". If
you then try "export as eps" or as any other of the many possible formats, it
will automatically fill in "name.eps" or whatever extension is appropriate,
in the same directory as the "name.fig". If one saves as a figure file
again, it gets this right too. So -- just fill in the name once, then every
other time you want to save or export it's necessary only to click "OK"
unless (unusually) wanting a different name. That strikes me as pretty basic
and sensible. It's seldom wrong, and it's similar indeed to many
word-processors, image-editors etc.
Now consider matlab R2006b (linux, at least). Save a figure as
"name.fig".
Then try "save as". Initially, the dialogue comes up as "save as type =
matlab figure" and the name is still "name.fig" (which is fine). Change
the "save as type" to, for example, EPS. What happens to the name? It
disappears! Or, try changing the name to "name.eps" first, then selecting
the type -- it still disappears. Compare to the helpful behaviour of Xfig.
Not very important, you might think, but after recently writing a work
with
about 40 matlab and 20 xfig figures, each of which needed quite a few
re-openings and re-saving as both fig and eps, and each of which had a much
longer name than just "name.*", I really noticed the difference. Of course,
one gets in the habit of first copying the name up to the dot, then pasting
this in the blank space and adding the extension; but this is the sort of
thing one would expect to have to do for a beta-release of some little-used
program by a part-time programmer, not a very expensive and widely used thing
like matlab! What's going on?
Note that I have setappdata(0,'UseNativeSystemDialogs',false)
in my startup.m file, as this is needed to avoid another bug. I think the
same behaviour occurs without this.
[THREAD ID:1-14PCJH].
A symbolic link in a POSIX system is a file that points to another file
(including possibly a directory or other symlink). System-calls and most
programs (sensibly written to use the system's functions for handling links)
simply read a link to a file/directory as if it were that file/directory, and
if asked to delete a link they delete the link... In matlab 7.0 deleting a
link to a directory deleted that whole directory, which is pretty well
guaranteed as _not_ what is wanted (and also not something that any other
program of my experience would do). Seems ok now, but why wasn't it ever
thought of or tried?
[THREAD ID:1-37RH87].
I've recently reported that matlab's JVM tries to reserve loads of memory
(>1GB) on AMD 64-bit systems, and if it can't do this (e.g. because
of "user-limits" on memory) then the startup just has a java-crash. This is
very silly behaviour: checking for limits, or trying to reserve less until
it works, would be more helpful. It took a long time until I found the
underlying problem; until then I was just puzzled by why the program simply
crashed on start-up every time.
Good attention was given by support, who have "passed it on" to development,
but it's not very good that it happened (as usual, just when I needed to
work!).
[THREAD ID:1-389FGH].
Again, in the latest version, I noticed that previously small (10 - 20 KB)
figure files were becoming enormous -- several MB -- after a few edit-save
cycles. It turns out this is a consequence of use of HDF5 MAT-file format.
This was well dealt with by support, and accepted as some sort of problem.
One wonders: a) Why was this not thought of / noticed before;
b) Why can one not select the figure data and general MAT-file formats
separately, so that advantages of HDF5 can be used where they're really
needed, in large data files rather than just a figure?
Page started: 2007-01-27
I have many scripts where the "input" function is used in a loop, to get a
number or string from the user then do some sort of calculation or plotting.
Most of the (real) time in such scripts is taken on input() waiting for the
input data and printing figures
In earlier versions, 6.x, the printing dialogue was not nice but it worked.
The "not nice" was that I seem to remember that there was no (at all obvious)
way to save one's settings for the print dialogue. Somewhere around 7.0 or
7.1 the linux version ended up always printing figures so they came out much
too big, with the bottom left corner around the middle of the page and much
of the figure missing. I could only solve this (after using support and
spending hours going up and down the corridor to collect bodged print-outs)
by avoiding altogether the UI print, and using always the "print" command.
But, since R2006b (or perhaps even a) the printing has worked again.
As usual, the question arises, would such an inconvenience have persisted so
long in the ms-windows version?
First, in versions around 6.5, trying to make this character caused a freeze
of matlab. Then in 7.0 it was just not possible to make this character with
the normal Swedish keyboard in linux-based systems. ~ is needed, amongst
other things, for logical negation.
Old problem of overwriting figure files with eps or other format.
If a figure had been saved as, e.g. type eps or png, using the GUI controls,
then if in the same matlab session another figure (in .fig) format, was
opened and subsequently modified then saved with the "Save" icon button, then
it would be saved in the last used (e.g. eps or png) format, but into the
*.fig filename that was opened... Utterly undesirable behaviour, with no
way of retrieving the modifiable .fig file. This bug persisted for several
releases in spite of loud complaints.
Figure save dialogue
me: Figure save dialogue still awful: if one types 'save as' then
modifies a filename to .eps instead of .fig then changes the type to
'EPS', one hardly expects the name to be automatically changed back to
.fig. Look at almost ANY other program (e.g. xfig) for the obvious
RIGHT way to do it: changing the type changes the extension to the
appropriate one and preserves the basename!
support: We have not been able to reproduce this problem in our latest release
R2006B. We tried both Linux and WinXP platform but it appears to work as
expected, i.e. not change the filename extension back when you change
the filetype.
Subject: Matlab doesn't cope with symlinks
Subject: java memory problems.
Subject: figure save: HDF5
Last change: 2008-12-07