See also the main matlab page of this site, for parallel pages.
Note: in case the following list seems wholly negative (which it is), I do appreciate that matlab has many excellent features, for example in its collection of so many compiled and m-functions, toolboxes for all kinds of applications, simulink, plotting ability, etc. The thing that has irked me and colleagues about it, particularly a few years ago, is the number of little problems, usually of an interface sort, that could so easily be fixed, and yet generally aren't for a long time. In Free software one might quite happily tolerate such things if the core functions work well (OR, one might try fixing the problems): but when one's employer is paying a small fortune for the provision of software, one might hope for a smoother ride.
Addendum, 2009-10: in the last couple of years, things really have begun to look as though there's some more care in the right direction: things are looking up, a bit. There's still plenty to annoy, but there's some apparent interest in fixing it.
I don't really have time to keep this at all up to date: just a few recent points are listed briefly before the old set (of which one or two might even be fixed by now!)
As of the 2008 versions, there's a requirement of going through a
host-unique registration process for every copy of freestanding
matlab or at least the license-server part of network licensed copies.
The following was wrong:
From a recent attempt at installing a recent matlab so that it would
get its licence from a licence server, it seems that even for this
situation there's a need of host registration (please let me know if
I'm wrong here: the change messes up my nice system of all computers
getting their programs from a central server by automatic copying or
by NFS mounts, then using a single server for the licences).
Actually (thanks, support!), by selecting 'Manual registration'
in the first dialogue, then giving a valid 'file installation key' (FIK)
for network-concurrent licenses, then providing a licence file that refers
to a working licence-server, it does still work to run a single
copy of matlab over multiple hosts, either by NFS or by automatic syncing.
As usual with restrictions on software, this is a way to waste a lot of time for legitimate users, while doing presumably very little to thwart anyone else, considering the widespread availability of cracks for popular programs. I wasted at least an hour (when trying to get a newer version in case the instrument control toolbox actually supported some useful types of devices under linux) on trying to install, then organising the admin with the licensing password to come to the lab.
It's particularly silly as it's largely useless as a protection.
It apparently works by network card ethernet address. By simply
changing this to the required value of the host where a copy was
registered, e.g. ifconfig eth0 hw ether 00:11:22:33:44:etc
one could get the `wrong' host to run it too, if this is the only
check that's made; they'd just have to be on different subnets.
I'll avoid these later versions, anyway; too much hassle to have
problems any time one changes a netcard, makes a different card
be the first one, etc.
Until about 2007 there was just basic IP networking support in this toolbox: the ms-windows version had GPIB, USB and VISA support, but in spite of there being drivers available from NI (national instruments: a manufacturer of many GPIB devices and general instrumentation things) for all these things for linux, matlab seemed not to want to get round to interfacing to those drivers.
But in spite of this version of ICT not supporting several popular types of instrumentation hardware, its `tmtool' program shows these classes under `hardware', causing the feeling that they ought to work! Better to show what's really available, which is basically what could be done with absolutely basic networking functions in Perl, Python or other easy, freely available languages.
One positive thing was very good support when I complained (Autumn 2008,
about r2007b) about the apparent lack of GPIB support.
I was given a file to add x86 linux matlab ICT support for NI's VISA,
which provides (at least) GPIB support:
just put this mwnivisa.so into
$MATLABROOT/toolbox/instrument/instrumentadaptors/glnx86
(where $MATLABROOT is your matlab's basedir, and the glnx86 directory
may well need to be mkdir'd), make sure that the NI VISA library,
libvisa.so (NI-VISA-4.3.0 was said to be the version used for mwnivisa)
is available for linking by matlab (e.g. LD_LIBRARY_PATH=/path/to/libvisa.so),
and run matlab.
Then such commands as
v = visa('ni', 'GPIB1::1::0::INSTR') actually work.
Presumably I could have produced such a file by reading the documentation for the NI drivers and for interfacing C-functions to matlab: but a major purpose of getting the ICT was to avoid needing to do anything other than well-known matlab commands. Why not just make this work to begin with, I have to wonder?
(As of 2009, there seems to be a fresh wave of enthusiasm for getting
ICT good; I look forward to developments.)
Normal fprintf, e.g. in C or in matlab, takes arguments of destination, format string, and possible extra values needed within the format string. If one specifies a newline (\n) in the format string or some string value within it, there will be one in the output data, else there won't. The format string describes exactly the output: we expect fprintf(f, 'text') and fprintf(f, 't%st', 'ex') to give the same result.
Matlab's ICT's overloaded fprintf for writing the instrument objects has a subtle difference that has caused me wasted time (as usual). The mathworks explanation is that if the second argument contains a format character `%' then it and the following arguments are interpreted as in normal fprintf, but if the second argument is a plain string then this means that the format string has been omitted and should be treated as a default value of '%s\n' in which the actually given string argument is the contents of the '%s' part...
The consequence is that when wanting to send a plain string, and therefore using this string as the format string, there is an added newline, not explicitly asked for; on the other hand, when one does want to include e.g. some numeric variable, then there is a format character, and the normal fprintf behaviour includes only explictly requested newlines. In a function with some plain strings and some formatted numbers to send to an instrument, the inclusion of '\n' in the format strings caused errors (instrument not happy when it got empty commands from the '\n\n' at the ends of fixed string fprintfs, but it went very slowly when omitting these '\n's everywhere, as it then apparently didn't get sent the data until the next pure string caused a newline. Not until plenty of confusion, and eventually log-checking, had been done, was this funny characteristic of ICT fprintf picked up.
I defy anyone to justify this behaviour as reasonable: most users will assume the similarly named function to have the (sensible) behaviour of the well known function. The ancient recommendation of not giving the same name to different things should have been followed here. Of course, there's now the matter of balancing future users' problems with the already written programs of current and former users, some of which could be be broken by any change in the fprintf behaviour.
I'd also say that the notion of such defaults and `helpful' (`smart') behaviour
by functions is best avoided in general. An example: the plot() function
of matlab accepts input matrices to plot against a vector, and rather than
rigidly plotting, say, columns of the matrix against the vector (with error
if they don't match) it `helpfully' transposes the matrix if that would make
it work; this all very well until one day the data is such that the matrix is
square and the wrong parameters are plotted. Not a very critical example, but
the principle of clear definition and minimum of `surprises' (including
`helpfulness') strikes me as a good one.
I think I may have been fool enough to say, on some other page here, that printing problems were largely solved, quickly, in 2006 or so. But since sometime in 2007 the above message (`there are no properly configured printers on your system') has been normal when pressing `print' on a figure, although there are several printers, including a default, set up in CUPS and working beautifully for every other program... I won't even waste time trying to understand this. The command-based version is ok, e.g.
print('-dpsc2','file.ps')
followed by normal printing of the postscript file, e.g.
lpr file.ps(from the system shell, e.g.
! lpr file.pswithin matlab). Wouldn't even the most amateur peddler of programs feel ashamed at not finding and correcting such problems?
More: 2009: it's still not working in 2009 versions. There seem
to be some cases in which Java (yes -- that's likely the culprit --
the stopping working happened together with use of Java for printing,
so they say) gets happier for having some changes made to CUPS,
even if other applications are happy. I've got them looking at
the problem, anyway. For myself (Gentoo or RedHat) no amount of
CUPS fiddling helps, but using the system JVM instead of the
Matlab-supplied one does help.
To change the JRE, go to $MATLABROOT/sys/java/jre/ARCH
(where ARCH is your architecture, e.g. glnxa64),
and do the obvious necessary thing to use another JRE.
For example: with version R2007b, link or copy the new JRE to
a name and version such as 'jre1.6.0.15', then edit the jre.cfg
file to have this version-number; with version R2009b, simply
change the name of the existing 'jre' directory, and copy or
link another one to that name, e.g.
ln -s /opt/sun-jdk-1.6.0/jre jre; then
restart matlab.
I'm not very happy with such things, as there'll probably be
a time when some other Matlab feature doesn't work with the
system JVM, or when the system JVM changes and upsets things;
it's also rather silly that it shouldn't work ok anyway.
After opening a save figure file, the minor grids return even if explicitly turned off during or after the plotting operation that created the figure. This is seen in version 2009b (7.9) and some earlier.
The user reasonably expects the opening a /saved/ figure will result in the same figure being there as was saved. Not a modification of it... The minor grid is often a nuisance. It wastes lots of time when adjusting figures to get them just right for publication, if every opening and resaving also requires remembering to re-set grids.
Minimal example:
x=logspace(-3,3,64); y=x.^-0.5; loglog(x,y) ; set(gca,'xgrid','on','xminorgrid','off','ygrid','on','yminorgrid','on')This will give a plot with only the major x-grid. Then save it as a fig-file. (I use "save -v7" as the default format in the matlab preferences; but I've seen the same problem when using -v7.3). Open the figure: the x-grid now includes the minor points as well.
The example in the linked images is not uniquely bad; it's just one of
many annoying cases. Certainly, the placement is not too bad in many
of the cases, but it does seem strange that the algorithm should be
happy with interpreting this request for `best placement':
legend(legstr,'Location','Best');
as being fulfilled by this result:
matlabs_best_legend_location.png
rather than by something closer to the effect I achieved by a simple
drag with a mouse:
my_better_legend_location.png.
Just to make clear to us that we're not talking of completely different
criteria of goodness, note that the `help' about the legend command
tells us that the 'Location' setting 'Best' means
``least conflict with data in plot''.
Note: the above was for matlab R2007b (7.5); now, trying with R2009b
I see the result, particularly with 'Best' set, is pretty sensible, even
including a neat spacing from the axis edges.
Version 7. Here I'm using sp3. Others report problems with other v7 variants. Supposedly worked-around (that familiar concept!) with
setappdata(0,'UseNativeSystemDialogs',false)
which worked for me, but it's an enormous nuisance anyway, to have yet
another bug to cause confusion, debugging and wasted time.
How can such a thing not be fixed immediately - next release, or
interim update?
Why is mathworks' "solution" on a webpage that requires a user account
(I can't be bothered to spend even more time registering to look
at how to fix their buggy rubbish)? Perhaps they are a little
embarassed! That would be reassuring, since there's been little
suggestion before that such grave bugs aren't just ``acts of God''.
What sort of attitude to programming have these people? Do they think
it's like discoveries in physical science - we have to try it and see,
and perhaps people will later discover more subtleties that we missed?
No - this is just a bit of computer programming: it's clearly possible
for hundreds of other far less wealthy and employee-rich organisations
to make file-choosers that work, so how does matlab manage in so many
ways to make ones that don't, and still have the cheek to avoid fixing
it? Think what's needed, plan, write, check, check, check, respond
quickly to customer-observed bugs.
Plain `uigetfile()' returns a string as the filename.
Using the 'Multiselect' option, to allow multiple files, the return
type is still a string if only one file is chosen, but is a cell array
of strings if more than one file is chosen. This wonderful
behaviour ensures that more user code is needed to make the general
case work -- typically, check whether the return is a string, put it
into a cell array if it is, then deal with for n=1:numel(list),
... , end.
On several recent linux distributions (early 7.X series, 2006ish) matlab fails to use the -lgcc_s option to gcc when trying to link C++ libraries - the mcc processes fails with obscure error messages that don't help in identifying a problem! Although the fix is simple, mathworks seems (from website and emails) to think it reasonable that users should all discover the problem, find the fix and modify some matlab installation files, rather than that mathworks should simply fix the problem itself. The following puts it quite aptly, and the preceding message in the thread is more detailed. http://gcc.gnu.org/ml/gcc/2004-04/msg01041.html
As ever, the puzzling question is how anyone can fail to understand that if even a few users, let alone presumably all with at all modern versions of their operating system, will experience a problem, then why not fix it, at once?.
Clever! Stupdendous! All of version 7 up to the present (Nov 2005), at least on linux systems, exhibit the following amusing behaviour: save a figure as something other than a fig format (e.g. eps or jpg); now, without restarting matlab (but perhaps weeks later than the aforementioned save), click on a .fig matlab figure file to open and edit it; having edited it, click the inviting little "Save" button on the figure window.
Expectation: presumably, that the figure is saved as a figure file to
the original name, i.e. that the original file is updated with the
changes since opening.
Actual situation: the original file, xyz.fig is overwritten with the
new figure in the previously used format, i.e. one ends up with
for example an eps file in xyz.fig, so the modifiable figure is lost and one is left
rather confused by the names!
Absurd! Crazy! But, much more so, the attitude of the support personnel, who after several emails over the course of a year (and several releases) to persuade them, acknowledged the problem as a ``request for enhancement'', and suggested that it was reasonable that one would expect the previously used file-type to be used even to a contradictory filename -- ``that's natural; just don't use the "Save" button to save it..!''
A rather nice example of a competent program, also having files with a .fig extension, is "Xfig". When asked to export a file xyz.fig, one can specify the type, e.g. eps, and it will default to writing a file with similar base name and directory but with an eps extension. So the whole process of saving (fig) then exporting (eps) is four clicks and one name to write!
A common error is indexing into an array beyond that array's size. Lines of matlab code may have a dozen indices into perhaps as many matrices -- it is ridiculous that the matlab error message should be simply that "index exceeds array size", without specifying _which_ index and matrix.
Subject to manageable size, it would be helpful for the offending pair to be printed to screen; at the least, the matrix size and the offending index should be given. This is really basic, and would have saved me alone many hours of debugging. It _should_ be in matlab by default.
(Jan 2004 - I am told that more helpful messages are being worked
on)
(Nov 2005 - I see that, probably in the last release (Sept) the
messages in the case of (old-style) "index exceeds matrix dimension"
are indeed much improved. But I think it's not unduly negative to
observe
that this should have happened ages ago.)
(Sept 2006 - but now I see again some general "exceeds" messages
without details.)
Operators of the C style for increment, decrement,
accumulate etc. would make many lines of code a lot shorter, easier
to change, and therefore less error prone.
For example:
matrix(ind(:,1),2:5) = matrix(ind(:,1),2:5) + 4 ; is a
type of assignment often made, sometimes with a much longer
expression for the matrix part.
For this matter, other things like a=b=c=0; assignments would also
be very handy.
A note: GNU Octave has these operators, as well as double-quoted strings, direct indexing of non-variables, sensible negation symbol, convenient ways of setting defaults for optional input arguments, and more.
(Jan 2004 - has been suggested before, but no plans to implement
it)
The m-editor has the useful feature of popping up a display of the contents of variables as the cursor moves over the variable names. This does however not show variables within functions, unless they share names with workspace variables, in which case the variables are shown but may well be wrong in the context, unless they're globals. It would be nice if, at least for functions that have finished on error, the contents of functions could be shown.
(Jan 2004 - it has been pointed out by mathworks that this should
be possible when stopped at breakpoints in debugging mode. Still not
as desirable as having it always displayed correctly for the function
being studied.)
I assume from the primitiveness of the "help" command that the html
help with search facility is intended to be used for matters where
the user doesn't know almost exactly the function of interest. It
is often easier, particularly when writing code rather than using
Simulink, to have help available without starting a new window and
using the mouse. A further command, along the lines of the unix
"apropos", would be very useful, to match query words with a
database of words in the help files, and return details of likely
functions / help-pages for more precise searching with "help". I
have often spent a long time trying the find the name (or
existence) of a function for a certain task, and only doing so by a
long route through the "help" hierarchy and then resorting to
Google and other matlab users.
(Jan 2004 - this is due for whenever the next release is)
(Jan 2005 - I see no evidence of it, 1 year and one release and
several service packs on; perhaps the reply didn't actually
mean that the command form would be implemented but just that
a reference would be made to the GUI help browser)
(Nov 2005 - Hmm. Actually, the `lookfor' command does just this:
I have known of it since earlier this year, but a friend tells me it
has been around for years: the help people apparently didn't know this
and I had done plenty of `googling' on this request.)
Many such OSs are run on PCs with a scroll mouse whose scroll
button can also be used as the X-windows middle button. The scroll
is simply buttons 4 and 5 as seen by the the X-server - surely it
isn't hard to implement? I was told a year and a half ago that this
would be included soon, but the latest version (as Jan04) does not
yet have it.
(OK - at last - v7 got this, although the GUI file-chooser
at any rate still doesn't scroll properly)
Using the latest version (sp1 13.1, Aug03) there is still the problem that every time the system (X) keyboard layout is changed, even if matlab doesn't have focus before the layout is reverted, matlab freezes.
`killall -9 matlab' is now a toolbar button for this situation! I
have to write some reports and correspondence in other languages
with other characters, so it is hard to avoid such switches.
(Jan 2004 - it seems this problem is due to the JVM .. it remains
to be seen if this gets fixed soon. Of course, the next point could
obviate the need...)
(OK - v7 fixed this)
Matlab 13.1 and earlier java-based ones also freeze completely (see above) when special characters made with multiple keystrokes are typed. E.g. on some keyboards a plain tilde is made by an Alt-Key combination followed by a space, since the tilde is often used on top of other letters such as n. This problem does not occur in for example Femlab 3 or "Limewire", both of these being Java based programs: they just show a non-printing character. These special characters are not normally needed in Matlab programs, (though they may be, in strings, by users of certain human languages...) but can be useful in operating system commands given from the matlab window, for example for a home directory.
But the Matlab window is such a rubbish terminal anyway that perhaps it is better to give up using it thus. (v7 stopped the crash, but the multi-key characters still don't work, e.g. a tilde [negation operator] on a Swedish keyboard in linux/Xorg/kde; I see the same problem with other java programs, but not of course with any others - another java peculiarity)
(seems ok now since about 2006)
With R2009b things got distinctly worse in our configuration: 20s for
a start of the GUI on a fast 64bit system was often seen, even if the
program was clearly cached in memory; there was also a (possibly even more
annoying than watching Java grinding away) period of several
seconds of delay with no disk or CPU activity during startup.
Some advice from the licensing part of support suggested that licences
may (again) be causing a problem. Indeed, the times were halved by
removing a 'SERVER' line in a local file that had apparently caused a
slow remote host (no longer in use) to be tried. The times were still
annoyingly slow, but turning off the splash screen helped by a further ~5s.
With the most efficient licence settings and no splash, times became
similar to the older versions.
Details can be seen in startup_timings.txt.
It's well worth turning off splash for all users: on a GNU-based system
(where the '--' argument escapes subsequent leading '-' characters in
arguments) the following line can be added to the top of the
$MATLABROOT/bin/matlab script:
set -- "$@" -nosplashto disable splash for all cases.
Although the "multi-platform" idea sounds appealing for the range of platforms that Matlab is used on, use tells us this was not a good idea. Putting aside the distinctly ugly appearance, which I agree should not be _very_ important in a serious tool, the speed is bad enough to make use unpleasant on a local display, and sometimes unbearable across a (local) network.
Note that matlab is just the sort of program that might reasonably be expected to be used from a fast memory-filled server across a network, and that other programs with properly compiled GUIs are able to run on locally networked X-servers with little perceptible difference from local programs.
Even on ms-windows, devoid of network-transparent windowing, the matlab editor was so slow to start that I installed an old version (5.1.X) to make it tolerable for times of needing to open new files frequently. A local display on unix/linux is slow to change between open files in the matlab editor, and is delayed in scrolling. Some network displays, particularly with 10Mbps network, have _very_ long scroll/open delays, even when properly functioning programs such as those in KDE can open and scroll easily.
The greatly increased memory use and startup time over other versions is also a great failing since the use of the Java GUI, and I assume this change is mainly as a result of the Java environment.
For the potential advantage to the many highly-paying users, would it not be worthwhile to compile a proper GUI for each platform, and/or to provide source for a GUI with hooks to the "engine", to allow immediate integration into widely available GUI systems such as QT, etc?
(Jan 2004 - Improvement of the rendering speed is being
considered, but within the narrow confinement offered by the JVM.
i.e., it is down largely to Sun. Use of a user-compilable graphical
interface is to be passed on as an idea.)
I have not seen any poor behaviour with any other application when
running remotely.
Matlab sometimes doesn't let you type in a window.
I suggest that the text widget is rewritten.
(That was back in 2003 -- perhaps better now.)
The substitute of an "if 0, ... end" statement around the commented
block is not as clear as proper block commenting; it does not attract
the matlab
editor's colouring attentions to make it obvious as a comment.
(about 2006: now `%{' .... `%}' does block quoting -- good)
It is not possible to export a figure (e.g. as ps, eps) so that it
reliably looks as it did on the screen. Axes, text and
curves/sufaces seem to scale differently. When dealing with tightly
packed figures whose contents have been carefully manipulated to
get them right, and which are to be exported for a report, this is
a severe annoyance.
id est: "one would expect it to alter the font size properly
with scale on the figure window: the figure window should always be
wysisyg."
As examples, a very very simple example is given (from v6.5):
Original - a pixel grab of
the (default size) figure window
The EPS export by matlab
The same export,
converted to jpg for people who can't read eps...
Matlab's jpg export.
See how text that just fitted around the curve has shrunk or grown,
and how even the height of the lines (underscores) around the -100
on the Y axis has been moved in relation to the number. And the
matlab exports of jpeg and eps have had different effects..!
Some help: actually, several years on from receiving
this complaint, I should point out that one can get improvements,
including causing the exported figure's aspect-ratio to match the
one set on screen, by setting 'PaperPositionMode' to 'auto':
set(gcf,'PaperPositionMode','auto');
saveas(gcf(), 'eg.fig', 'fig');
print('-depsc', 'eg.eps');
to save as figure (for later manipulation) and as eps for
inclusion in a report. It seems to give quite good results
at least for placement of legends and aspect of axes not
being bodged as they would be without the 'PaperPositionMode'
setting.
The matters of the unhelpful error messages and sluggish GUI have,
particularly, made my use of matlab be quite unenjoyable, and have
made the expensive product seem far less polished and professional
in basic features than most free software, the graphical display
features being the only advantage.
I welcome other users to make further comments (nome@ntmm.org). The
"support" address at mathworks gave no help in spite of several
requests, but the "bugs" address, which was used concerning the
keyboard-layout crash, had a helpful respondent who commented on
many of the above points.
