What frustrates you about MATLAB? #2

Similar to what has happened with the wishlist threads (#1 #2 #3 #4 #5), the "what frustrates you about MATLAB" thread has become very large. This makes navigation difficult and increases page load times.

So here is the follow-up page.

What should you post where?

Wishlist threads (#1 #2 #3 #4 #5): bugs and feature requests for Matlab Answers

Frustation threads (#1 #2): frustations about usage and capabilities of Matlab itself

Missing feature threads (#1 #2): features that you whish Matlab would have had

@anyone posting a new thread when the last one gets too large (about 50 answers seems a reasonable limit per thread), please update this list in all last threads. (if you don't have editing privileges, just post a comment asking someone to do the edit)

[Ignatius Bramananditya Rivaldi]

Frustration/suggestion:

Can Matlab editor be set to Windows Default Set keybindings on Linux by default? The thing is that Ctrl-C and Ctrl-V for copy and paste is the standard for GUI apps everywhere even in Linux and the default Emacs Default Set keybindings breaks that.

Its even a FAQ now:

https://www.mathworks.com/matlabcentral/answers/263833-linux-hot-key-settings

https://wiki.nps.edu/display/RC/MATLAB+on+Linux+-+Windows+Shortcuts

Interesting quote from the second link:

When installed on Linux, the MATLAB Editor defaults to using Emacs style keyboard shortcuts (copy, past, etc.). This might be difficult for those new to Linux.

I have used desktop Linux for 5-6 years and I still find Matlab using Emacs keybindings surprising in a bad way

[Walter Roberson]

The thing is that Ctrl-C and Ctrl-V for copy and paste is the standard for GUI apps everywhere

Not on Mac, which uses ⌘-C and ⌘-V

Can Matlab editor be set to Windows Default Set keybindings on Linux by default?

Do you mean just for you (or for all people running MATLAB off of your installation)? Or do you mean that you want Mathworks to change the default ?

If you mean that you want Mathworks to change the default, I would not expect that to happen. emacs binding has been standard for Unix since at least 1983.

[Steven Lord]

Expanding on Walter's comment, if you mean just for you see the "Keyboard Shortcuts Preferences" section on this documentation page.

Answer 1

[Zoltán Csáti]

Before I started using Python this year, I was a happy MATLAB user. I still like MATLAB because I am efficient in it, but here are some things I don't like about it. I will sometimes refer to Python because that's what I have experience with. I do not indend to start a flame war, especially because I see the merits in both languages.

1. The community. There are some heavyweight MATLAB users (Walter Roberson, Image Analyst, John D'Errico, Jan, and I'm sure I missed many of you) who have immense knowledge and are also very active on MATLAB Answers. However, the forum is full of people whose posts do not show any research work. They expect complete solutions without showing any effort. When Python users raise issues on GitHub/Gitlab, etc., I don't have this feeling. Related: I also feel that the open-source nature of Python produces quality contributors.
2. Lack of momentum. There are too many awesome projects that stop because the maintainer a) lost interest or b) left the university and has no access to MATLAB any more. Being closed-source really hampers the development.
3. Ecosystem. I can only talk about areas I experienced, but Python (and now Julia) has such an extensive ecosystem and an active and responsive community, that one does not have to start reimplementing everything. MATLAB toolboxes sometimes provide a solution but university clusters often miss many toolboxes.
4. Editor. The MATLAB Editor (the classical one, not the Live Editor) is useful but misses some features that others have. As if the MATLAB linter was available for other editors too!
5. OOP. Reading the threads, people criticize the OOP syntax of MATLAB. To me, it is not a problem (Python also explicitly needs the instance as the first method parameter), but custom types are really slow in MATLAB. I would love to have (nearly) costless abstraction as in Julia or in C++; it happened to be that because of speed issues I had to sacrifice readability and turn to built-in types to achieve reasonable speed.
6. Lack of efficient data structures. Complex problems require fast hash maps, linked lists and other data structures.
7. Parallelism. The fact that open source tools support many levels of parallelism and MATLAB offers it in a toolbox is a big drawback. Moreover, launching parallel pools open new MATLAB workers that spend about 700 MB each! I didn't see any efficient massively parallel applications done by MATLAB.
8. Invoking C code, let alone C++, is difficult with the MEX interface. The really powerful MEX commands (see on UndocumentedMATLAB) are not documented and change all the time. You also cannot debug MEX code with MATLAB Editor.
9. To generate standalone application, you need an additional toolbox. Moreover, the MATLAB runtime is huge, so for a simple application, you have to download hundreds of megabytes. The startup time is also very slow.
10. TMW's focus on shiny features and the toolboxes. The core numerical algorithms changed very little in the past 20 years. To me, MATLAB's focus should be on computational mathematics (as it originally was) and not polishing the IDE and other secondary issues. Yes, they are important, but supporting tensor operations, introducing state-of-the-art ODE solvers (as Julia's wonderful DifferentialEquations.jl) would be more useful for a scientist. I would just highlight git support. If someone has to solve complex git-related tasks, they will use a feature-rich editor (such as SmartGit) or will use the command line. What I want to point out is that TMW spends its workforce on implementing many things into MATLAB that simply cannot compete with specialized tools (diff tools, git support, etc.). If they concentrated on the core of MATLAB (things that are unrelated to the IDE), all people could profit from it. I saw the tendency that computational scientists use MATLAB less and less because they need the features that other languages' rich ecosystems provide. Honestly, I am deeply disappointed that TMW tries to satisfy novice engineers instead of providing powerful tools. You are losing hardcore programmers and scientists this way (cf. points 1-3). I follow the release notes and bitterly recognize that in the last decade, almost no improvement was made for the core. Just the superficial features... Sigh...

I didn't write about the merits of MATLAB (there are plenty) because the question was about the negative aspects. My heart breaks to see how MATLAB fails to catch up with the state-of-the-art of computational science.

[Walter Roberson]

Thank you for your contribution, Zoltán Csáti

[dpb]

I'm too old an fogey to begin to pick up anything new so I can't really comment on the Python or Julia parts, etc., but I am in whole-hearted agreement with essentially all 10 items but particularly #10 and as longtime Fortran practitioner the near total abandonment of Fortran for mex.

[Andrew Janke]

I really hear you on the community and ecosystem issues. It seems like some of these wishlist/gripe issues could be addressed by third-party libraries, but it's not easy to author, share, or take dependencies on third-party libraries in Matlab like it is in some other languages. No package manager, no central package index (like PyPI or Maven Central), no virtual environments, no standard project/library layout or loading mechanism.

I know Toolboxes and Matlab Projects are making some strides in this area. Hope something comes of it.

For #5, you might be happy to know that the Matlab OOP execution engine got faster again in R2020b. In my benchmarking (https://github.com/janklab/matlab-bench), basic Matlab OOP operations like method calls and property access are now 2x or more faster than their Python equivalents.

[Zoltán Csáti]

@Andrew Janke Good to hear that, nice benchmark. Could you update your answer on Stack Overflow?

[Andrew Janke]

Yep, soon as I write up the code to format the results; they're just sitting in an ugly pile of JSON right now...

[Andrew Janke]

Oops – I forgot the Matlab License prohibits benchmarking Matlab against competing products. (Section 3.4.) I don't think I'll be able to share those results after all.

[Zoltán Csáti]

@Andrew Janke Probably they are afraid of competition...

Answer 2

[John D'Errico]

That the mind reading toolbox has never become available for general use? ;-)

Truly, that scares me just a bit if it ever truly became a reality, so not a real frustration.

So what frustrates me? As new capabilities are introduced into new releases, we find that the old tools stay around. This is necessary for backwards capability. And backwards capability is one of the things that makes MATLAB truly great, that I have nearly 35 year old code that still runs. But that leaves us with bloat, in the sense that we now have multiple tools with similar capability. New users find more stuff to learn. The result is a language that is not as clean, not as easy to use as I want.

For example, we have both strfind and findstr. If you read the help for findstr...

findstr is not recommended. Use CONTAINS or STRFIND instead.

But findstr remains in our universe. One day it might disappear. But when you want to use a code to do that, does anybody really remember which of findstr or strfind they SHOULD use? Which is the recommended code, which is deprecated?

I can offer other examples. We have delaunay, delaunayn, delaunayTriangulation, and triangulation. We even have alphaShape, which can be made to produce a delaunay triangulation if you know how to use it. But not all of those tools are truly compatible with each other. What are the differences? Sigh.

How about interpolation? There is the interp1/interp2/interp3/interpn family. But then we have griddedInterpolant. A different tool. Not compatible with the others. And griddedInterpolant requires an ndgrid call to use it, whereas the others rely on meshgrid. Sigh. While I prefer ndgrid to meshgrid because of the x/y inversion issue when you go to n dimensions that surely confuses people, but this difference will surely cause problems.

Likewise, for scattered interpolation, we have griddata. But then we have griddatan. We have scatteredInterpolant. And as confusing, there is no griddata3. griddata works in 2 or 3 dimensions. So they do similar things, but new users then need to learn about 3 tools.

There are other examples. For example, some toolboxes introduce capabilities that already exist in MATLAB. So if you have the correct toolbox, then you get a tool that replicates functionality that already exists. Yes, the new tool in that toolbox probably adds some new feature the author thought was useful. But again you have a source of confusion, especially a problem for newer users. An example of this is xcorr versus crosscorr. You get one from a toolbox.

Yes. I understand the reason for the various tools. But the result ends up as bloat. If I want to do X, then there should be a direct way to do X, ONE way. Not 10 ways, all of which have subtly different interfaces.

Is any of this really a major problem? Well, no. You learn how to use what solves your problem. And gradually, you learn about the alternatives.

I still love to use MATLAB. I just wish it were slightly more perfect.

[dpb]

Amen, brother!

And there's the Statistics dataset which was then introduced into base product more-or-less as table -- similar functionality but incompatible syntax.

The whole new bunch of replacement histogram and binning functions--also incompatible behavior.

And it goes on and on and on ...wonder just how much of the slower response is owing to all this extra baggage?

What would be the possibility of forking development to build a new product that keeps the best of the new and venerable but doesn't worry about the really, really old legacy stuff.

I'd give folks who have those apps a nonexpiring license for the present release but no new features; new sales and development goes with the svelte (and hopefully, much leaner/faster) release.

Then, be more disciplined in introducing new features into the wild before they're ready for prime time so don't have this duplication like with dataset when it wasn't quite what was hoped for.

The allowing toolboxes to have so many overall useful goodies that then get by public demand moved to base package but always, it seems, with twists, should also be greatly reduced.

[Rik]

Regarding your last point; I was amazed that TMW (have I already earned the nerd-status to be allowed to use this abreviation, or do I need to stick around for a few years longer?) introduced the boxchart function in R2020a. Why not move the boxplot function to base Matlab instead (along with the quantiles function, which seems to be the only part that didn't survive the move)? Now you have two functions that have the same job, but a subtly different syntax. And the second one returns 6 objects per box (without documentation). Great if you want to dive in and change the appearance, but a bit strange considering the OOP-direction of the past years. At least the doc for boxplot refers to boxchart.

About the legacy support: I really like that you can call cellfun with the char input which makes it run a lot faster. This is one of the few(?) exceptions where legacy code runs faster.

A=cell(10,12);for n=1:numel(A),A{n}=rand(randi(20,1,2));end
FSpec=['time elapsed: %.1f ' char(181) 's\n'];
fprintf(FSpec,10^6*timeit(@() cellfun('prodofsize',A)))
fprintf(FSpec,10^6*timeit(@() cellfun(@numel,A)))
fprintf(FSpec,10^6*timeit(@() cellfun(@(x) prod(size(x)),A)))

One cellfun pet-peeve: why didn't they use 'prodofsize' instead of 'numel'? Did they expect people to string this together like this?

dimcount=max(cellfun('ndims',A(:)));
out=ones(size(A));
for dim=1:dimcount
    out=out.*cellfun('size',A,dim);
end

Or did the numel function not exist when they introduced cellfun?

Rabit hole time: this is no longer really documented, but this is apparently working Matlab syntax:

numel([],1,[2 4 6],1)

I hardly ever work with user-defined classes, but apparently this is the way Matlab used to determine the expected number of outputs for subsref. Since R2015b you're forced to use numArgumentsFromSubscript instead (I don't know what you would have to do if you want your class to work on both, you probably have to overload both).

[Steven Lord]

From my perspective:

Some of us individually, and absolutely MathWorks as an organization, has learned more about how to design and implement code over the lifetime of the organization and our tenures in the organization. Certainly the code I write now doesn't look the same as the code I wrote when I joined MathWorks nineteen years ago. I still (usually) recognize my own coding style, though I have surprised myself by asking "Who the heck wrote the code that way?" only to realize by doing some archaeology in our source control system the answer is "Some hack named Steve Lord." ;)

Some of those changes are related to the introduction of new tools and constructs. When I started, MATLAB didn't have a shipping unit testing framework, anonymous functions were still a couple years in the future, graphics functions returned numbers instead of handle objects, and in fact handle objects (and the classdef-based class system) hadn't been developed. [I was involved in reviewing the design for the classdef-based class system over a decade ago.]

Others represent us understanding that certain patterns and anti-patterns exist. [If we were to redesign the language now, personally I would suggest that eval end up deep in an internal package and/or have a much less discoverable name.]

As for the specific case of dataset and table ... that "more-or-less" in your description hides a lot of lessons we learned watching how people used dataset that led us to what we believe to be a better design for table.

[madhan ravi]

19 years!!! Wow.

[dpb]

Just a youngster, still... :)

That would have been the same year I went off on own and returned to the farm and began the transition to turning the consulting gig into the sideline. I'd've guessed you were @TMW before then.

I was pretty keen on picking up the dataset when it came out -- it had a lot of useful functionality for the type of data I was seeing a lot of at the time...

I was/am also pleased a similar functionality ended up in the base product where (imo) it should have been from the start instead of being introduced in the toolbox.

Just disappointed the direction taken to not have a more thorough beta test process in which such warts can be found and a final direction taken that obviates the duplication or that can't/couldn't find a way to clean the one up to be the latter.

Didn't mention the issue of namespace proliferation/pollution this also causes.

Surprised nobody's commented the fork idea -- even to say it's ludicrous! :)

[John D'Errico]

But that is the problem. I truly want MATLAB to improve. Were it to stay stagnant would mean it would be now long forgotten, just another dead programming language, remembered fondly by some, and as a joke to others.

I just want it to rise fully formed from birth, perfect in every way. And THEN it can stay stagnant, as how can you improve on perfection? Hey, dreams usually are a bit silly.

[dpb]

I wasn't suggesting the main product remain stagnant but that TMW fork the development and let those with legacy apps that need that backward compatibility have a version for that purpose (basically only for that purpose altho I don't know I'd go so far as to prevent writing new stuff with it; maybe for noncommercial work only as part of license for new development.

Then the forked version could be the Phoenix... :)

[Sindar]

One related thing that I noticed recently is some stuff with the documentation search:

Great: "not recommended; use histogram instead" is right there

not-so-great: histogram is not one of the top results

Is there a way to boost the listing of common & current functions?

Answer 3

[Rik]

Sometimes things are on the edge of being documented or are almost a bug. An example:

It is relatively common knowledge under Matlab veterans (at least those I see posting on Answers) that the legacy syntax for cellfun is much faster than providing a function handle (which is faster than providing an anonymous function).

c=cell(20,30);c(randperm(end,end/4))={rand};%generate some data
timeit(@()lega(c));% the run feature might return an inconsistent timing, this should help
t=[timeit(@()lega(c)) timeit(@()hand(c)) timeit(@()anon(c))];
fprintf('%.2fms ',t*1000)

0.31ms 41.80ms 152.93ms 

But it turns out the result is incorrect for strings. The reason is that the legacy syntax doesn't call overloaded methods (as the documentation explicitly states). The problem I have with this, is that this sounds like it would only apply to user-created classes, or to classes that are exclusive to a toolbox. It turns out that assuming fundamental classes will work, will burn you in the end:

% function handles are a fundamental class as well, but can't be empty
fundamental_classes={logical([]),string([]),char([]),int8([]),  int16([]), int32([]), int64([]),uint8([]),uint16([]),uint32([]),uint64([]),single([]),[],table([]),timetable('Size',[0 0],'VariableTypes',{},'RowTimes',datetime([],[],[])),{},struct([])};
for n=1:numel(fundamental_classes)
    if ~isequal(cellfun('isempty',fundamental_classes(n)),cellfun(@isempty,fundamental_classes(n)))
        fprintf('For %ss, the legacy syntax doesn''t match the modern syntax.\n',class(fundamental_classes{n}))
    end
end

For strings, the legacy syntax doesn't match the modern syntax.
For tables, the legacy syntax doesn't match the modern syntax.
For timetables, the legacy syntax doesn't match the modern syntax.

%(local functions must appear at the end of the post for the run feature to work)
%call the functions in a loop to make them take longer
function lega(c),for n=1:100,cellfun('isempty'     ,c);end,end
function hand(c),for n=1:100,cellfun(@isempty      ,c);end,end
function anon(c),for n=1:100,cellfun(@(x)isempty(x),c);end,end

My main problem with this is not that you need to manually test things like this if you plan on taking advantage of arcane features. My problem is that Mathworks discourages optimizing your code for how Matlab works internally. When I read "this doesn't work for overloaded methods" I understand "though luck, you can't use this for custom classes, but vanilla Matlab classes are fine". In this case I should have read "dig deep in your Matlab install (e.g. with which) to try to figure out which data types use an overloaded method". Bug or feature? I think reasonable minds can disagree.

I found a similar issue where this page seems to suggest Matlab uses UTF-8 (or even the full 21 bits) to encode chars internally, while it actually uses UTF-16, as mentioned here. (on closer reading the first page could be construed to only apply to files and byte streams, but this lack of clarity is not usual for Matlab documentation)

[Adam Danz]

Most entertaining read of the day award goes to Rik!

[Rik]

😂 Thank you

[Jan]

Thanks Rik. I assume, that this is a bug.

Older Matlab version contained the C-MEX source cellfun.c . It is easy to insert a mxIsOpaque check to call @isempty instead of mxIsEmpty() for these variables. Then even {string([])} is recognized correctly as empty.

I've tried this and to my surprise a straight C-mex function checking mxIsEmpty or mxGetNumberOfElements()==0 is 2.5 times slower than the built-in cellfun even for standard data types. In both cases only one thread is used. So obviously the buit-in cellfun is not a simple C-Mex function anymore.

[Rik]

Thank you for digging into this. I'm quite sure I fully grasp you test, but it is interesting to see another angle of this.

For the record, the customer service person I had contact with claimed this was a bug in the documentation, not the function. I still disagree, but it's their program.

[Adam Danz]

@Jan, which older version of Matlab contains the C-MEX source file? What's mxIsOpaque? Looking fwd to learning more about this.

[Jan]

I've worked with 4.2c to 6.5.1 and 2009a. I cannot check this currently, but at least in 6.5 the source of many C-mex source files has been included: histc.c, ismembc.c, ...

For mxIsOpaque see e.g. https://www.mathworks.com/matlabcentral/answers/330929-how-to-access-matlab-string-data-in-mex-c

Answer 4

[dpb]

Switching named parameter names for newer functions to not be compatible with old -- from the time of textscan on which goes way back, the parameter was 'headerlines' for the number of headerlines to skip. This followed w/ readtable at least; I forget about who else, but is well-established tradition.

Then up and come along the new readtimetable, readmatrix and friends and voila! it's now 'NumHeaderLines' . While perhaps could have been argued back in the beginning, once it was established, there's no reason to change just to change.

I will grant that some (I haven't tested them exhaustively, may be all) at least also recognize 'headerlines' as well -- that's a start.

But, it isn't reciprocal--the old guys weren't patched to accept the new parameter name so if one gets trained to use the new, then have typos for the previous functions.

Where are the user-interface design folks in the internal design reviews that let this happen??? Doesn't TMW have a specific part of the design review team to try to create and enforce consistency?

Answer 5

[Andres]

The year is 2020, and although Matlab may do a good job with autoparallelization, I find it frustrating that parfor, parsim etc. are still reserved to an extra toolbox. Parallel computing is just state of the art today.

Considering the competition, I think it would be a smart move to include at least some limited features of the Parallel Computing Toolbox into plain Matlab/Simulink. This could even promote the toolbox to plain Matlab users.

Answer 6

[dpb]

Stuff like <heatmap-axis-labels-printing-vertically> and <how-can-i-change-the-pspectrum-time-units>.

Introducing all these mostly opaque graphics objects that users can't get to to fix up for cases not foreseen by TMW.

bar is another abomination have complained about for 25+ years -- there are any number of threads on Answers about annotation for it that have answered over and over.

Not to mention hatching patterns and a much larger supply of prebuilt colors/patterns for automagic cycling...

And last, but not least, the butt-ugly "0" at the origin of the default axes instead of matching the rest of the formatting..yes, it comes that way automagically because of the default '%g' but it's still ugly as sin. :)

[dpb]

"bar is another abomination have complained about for 25+ years -- "

I just saw this complaint from earlier this year next door to the above--I will give TMW credit they did finally uncover the xData position so one can label bars without having to use hidden properties. This is a far cry from having a full set of properties settable for the bars including labels, location, etc., etc., that would be the (imo) proper implementation.

Answer 7

[Bruno Luong]

FIND(..., 0) throw an error.

>> x=rand(1,10)>0.6

x =

  1×10 logical array

   1   0   1   1   1   0   0   0   1   1

>> find(x)

ans =

     1     3     4     5     9    10

>> find(x,2)

ans =

     1     3

>> find(x,1)

ans =

     1

>> find(x,0)
Error using find
Second argument must be a positive scalar integer.
 

Why MATLAB prefers to throw an error rather than returns an empty array is a mystery to me.

[Rik]

What would be the use case for find(___,0)?

[Bruno Luong]

Typically when N argument is from some calculation that can be 0 or not.

As example I just bumped into the ERROR when I do this code, I must redefine FIND that returns [] when N is 0 (see MYFIND()) as workaround, that is silly.

Beside that it make perfectly sence mathematically to returns [] for N == 0. The fact that FIND(...,0) must be [] is similar to these

• SUM([]) == 0,
• PROD([])==1,
• FACTORIAL(0) == 1,
• ZEROS(0) == []

which are all implemented as such.

Answer 8

[per isakson]

It frustrates me that else if is legal (R2018b)

%%
if length(c) > 1
    d(end + 1,1) = 1;
else if length(c) == 1      %#ok<SEPEX>
        if n > 0
            ia = 1;
            return 
        end
    end
end
%%
a = 1;
if a == 1
    b = 17;
else b = 17;    %#ok<SEPEX>
end

Doc says: "Avoid adding a space after else within the elseif keyword (else if). The space creates a nested if statement that requires its own end keyword."

It may be by design, but it still frustrates me.

When is a comma or semicolon required as separator between "keyword" and "keyword"/"statement"?

%%
a = 1; 
if a == 1  b = 17;  %#ok<SEPEX>
else       b = 18;  %#ok<SEPEX>
end
%%
for jj = 1:2  a=jj^2; end 
%%
while n<=3 n=n+1; end

[dpb]

But how is it to be known for certain the space is a typo and user did not intend the nested if?

[Walter Roberson]

elseif is not appropriate for the situation where the code would look like

else
    if test
        some code
    end
    final code within else
end

[dpb]

But are you going to actually enforce coding practice in the language?

It's still legal code even if not ideal practice.

[Adam Danz]

Under some contexts it's not legal to separate commands by a space or sometimes a warning appears such as

I'm not arguing that else if should also be illegal since I prefer leaving it up to the user to understand the syntax but just wanted to point out the enforcement of rules in similar contexts. The addition of semicolons would avoid all of the errors and warnings above and IMO else; if is more readable to inexperienced users than else if and a warning message could point that out.

[dpb]

I also misread Walter's intent...I'm in agreement with that comment entirely; which puts mine out of context with it.

Answer 9

[Paul]

When the debugger stops at a breakpoint, why does the focus and cursor go to the breakpoint, as opposed to the command line? I always start typing and corrupt the file being debugged. Is there any utility in having the cursor and control at the breakpoint?

[Steven Lord]

Does deselecting the "Automatically open files when MATLAB reaches a breakpoint" preference in the Editor/Debugger Preferences do what you want?

[Paul]

Yes, yes it does! Thanks.

Question: I can see why a user would want the file opened with an indication of which break point is reached, but is there any utility in having the focus and the cursor at that point? Or is it just a thing that opening the file can't be decoupled from focus and cursor location?

Answer 10

[Paul]

The documentation. I hate to say that because I do think that TMW puts a lot of effort into the documentation, which makes it all the more frustrating when

a) I can't find something that I think should really be in there (and may be, but just not easily found)

b) When I can't systematically search through the contents to find the right page. I run into the issue all the time in the Simulink documentation, and the most frustrating think about this is that I distinctly recall that at some point in the past navigating the contents was simple and intuitive and quick.

Obviously, the documentation is easy to use when one just wants to look up a function or a block. So I'm really talking about those portions of the documentation that need to explain concepts.

As an example, I was just poking around in the Control System Toolbox looking for a discussion on specified vs. unspecified sample times for discrete time systems. How does that property affect results? What about connecting models with specified and unspecified sample times? When to use one vs the other? Thinks like that. Couldn't find it, though it seems to me that's pretty basic stuff for this toolbox.

[per isakson]

I couldn't agree more.

Currently, I try to understand what effect Enabled true/false has on the behavior of a AddOns Toolbox. I have both a sandbox and an installed AddOns of my toolbox on my desktop. What surprices are I in for?

So far I only learned that Enabled means enabled.

[dpb]

And the change from help giving the text listing to the HTML doc -- which then has parts which end up with toolboxes with competing/overlying functionality/naming clashes which come up first instead of the base product so one then has to go find the version wanted.

Like what prompted this rant is that intersect just returned a graphics object version instead of the base product...

Answer 11

[Bruno Luong]

If would be greak MATLAB can do auto-expansion-like for array concatenation

>> A=1:4

A =

     1     2     3     4

>> B=[0;
      A]

B =

     0     0     0     0
     1     2     3     4

"Array" means numercial/cell/struct arrays, string and table

[Rik]

I bet it would be very tricky to figure out a robust method to determine which value should be expanded, but this would be a very useful feature, especially if you are filling a large array with sub-arrays.

[Walter Roberson]

I find that automatic zero expansion in particular is what I encounter the most often, with the occasional ones expansion and the occasional nan expansion. At the moment, I cannot bring to mind times that I used anything other than those as mass padding. I guess I must have used 255 at some point though.

[Bruno Luong]

@Rik: Well, no it's quite easy. The rule is exactly like auto-expansion and bsxfun. The dimension with length==1 wil be expanded to match the other, so more complicated than this simple rule. I have done here BSXCAT.

My function is not too fast, cannot be invoked with bracket syntax, no benefit from jit accelerator. All that can be handled if TMW implements it.

Answer 12

[madhan ravi]

If find() operates along dimensions would make things a lot easier.

[Bruno Luong]

+1. Really frustrated not able to call FIND along a specific dimension(s).

[Rik]

As a workaround you can use permute to reorder the dimensions, but I admit a built-in option would be nicer.

[Walter Roberson]

If this were to be changed, then it would be useful to also add a way to return the indices per-dimension (e.g., per-row, per-column), which should probably be done as a cell array even if the count is set to 1

This would be accompanied by an extension of sub2ind() to convert the cell arrays into linear indices.

For example it would be useful to be able to find the indices of the first (or last) element that met a test, per-row or per-column, and when you do, you probably want to be able to index using those values, but they are probably row or column relative, and the current methods to turn row or column relative indices per column (or per row) into linear indexing are a bit clumsy.

[Bruno Luong]

How PERMUTE would help? For example what would you do for the workaround like this situation: I want find 1 element along first dimension of

>> B

B =

  5×5 logical array

   1   0   0   0   0
   0   1   0   0   0
   0   0   1   0   0
   0   0   0   1   0
   0   0   0   0   1

>> dim = 1;
>> [~,loc] = max(B, [], dim) % This is my workaround

loc =

     1     2     3     4     5

>> find(B, 1, 'first', dim) % Now
Error using find
Too many input arguments.
 
>> find(B, 1, 'first', dim) % would love to have this R2050a feature sooner
ans =

     1     2     3     4     5

[Walter Roberson]

Bruno, what would you propose the output should be for the case where the count is not 1? Taking into account that some searches along the dimension might find the full count and some might not.

For that matter, even if the count is 1 there is potential problem. For example,

B = [1 0 0; 0 1 0; 0 0 0]

then for column 1 and 2 the search would succeed but not column 3, so if a vector is to be returned then it would have to be the vector [1 2 []] . find() has no current semantics for returning something like [1 2 nan] for the case where the search does not find the full count.

[Image Analyst]

madhan, can you give a small example matrix and what you'd expect the output to be if you used find() in the two directions (vertical and horizontal)?

[Bruno Luong]

Similar to CELLFUN, ARRAYFUN that uses 'uniform' TRUE/FALSE input to let user decide.

In case of FIND, it can be even automatically decided: if N argument is provided output is an index ARRAY, otherwise it returns as CELL. To be precise one can imagine as the following:

For p-dimensional A of size (n1 x n2 x ... x nd x ... x np)

FIND(A, N, 'first'/'last', dim) returns numerical array (n1 x n2 x ... x N x ... np). The ouput result contains 0s in trailing in case there are less than N indexes found along the dimension d. I think 0s is better than NaN, since it would be similar to the way ISMEMBER, UNIQUE deal with non-existing element. It also doesn't have speed penalty as with NaN processing.

FIND(A, [], [], dim) returns cell-array (n1 x n2 x ... x 1 x ... np) where each cell element is the vector array of indices of suitable length.

User might eventually force CELL output even when N is provided by set 'Uniform' flag to FALSE.

[Bruno Luong]

@Image Analyst "madhan, can you give a small example matrix and what you'd expect the output to be if you used find() in the two directions (vertical and horizontal"

To me pretty similar to FIND/IND2SUB, it returns according to the number of outputs at the caller

M = rand(2,3)>0.5
[linearidx] = find(M)
[row,col] = find(M)
% or more generic
A = rand(2,3,4);
[i] = ind2sub(size(A), 20); % A is considered as 1 x 24
[i,j] = ind2sub(size(A), 20); % A is considered as 2 x 12
[i,j,k] = ind2sub(size(A), 20); % A consider as 2 x 3 x 4

Answer 13

[per isakson]

Which do you prefer 'MultipleDelimsAsOne' or 'CollapseDelimiters'? Now and then I use the correct name in the wrong place.

I wish: a popup asking me whether I want the other. That would save me a bit of frustration and lower my blood pressure by several pascal.

Answer 14

[Sindar]

Livescript complaints

First off, they've come a long way since I tried them on release. But, there are still some issues:

Dropdown controls

• The "item value" box is tiny
• Keeping track of item label - item value pairs is unnecessarily complicated by the vertical arrangement (vs a table-type view)
• poor auto-updating of labels/values when the other is changed
• pasting code into the value box often separates lines unexpectedly (it seems to sometimes cut at mid-line whitespace)

output character limits

there seems to be no way to convince the livescript to print characters beyond a certain limit. For example,

for ind=1:10000
    fprintf('Sample %d has been processed\n',ind)
end

and

for ind=1:10000
    disp(['Sample ', int2str(ind), ' has been processed'])
end

both print only to

Sample 1971 has been processed
Sample...

Copying Output

• cannot select text in output
• copied text does not always match displayed text (e.g., copied cell arrays say "1×2 double" while output displays the numbers)
• unclear rules (moments ago, I learned that what's copied depends on where in the output box I right click)

Export to PDF

• can't read long code lines
• displays variables differently (e.g., doesn't truncate table rows)
• doesn't warn if code has been changed without re-running (so code and output don't match)

Minor gripes

• add "run from beginning to current cell"
• code prediction seems better than for normal scripts (even aside from the fact that variables are more often already evaluated when working with live scripts)
• not enough heading levels
• I'd prefer controls default to not running anything
• "unable to run code analysis... is an invalid Matlab file name."
• no way to collapse output (vs clearing)
• no way to fully un-collapse output (e.g., display full table instead of scrolling)
• figures are saved with "Visible" = off, so they don't open as expected

[Mario Malic]

Dropdown controls

• The "item value" box is tiny - You can increase it, click once to select the Dropdown, then once moreon the value box, you'll get these "grips" to increase it
• Keeping track of item label - item value pairs is unnecessarily complicated by the vertical arrangement (vs a table-type view) - not so clear what you mean by this
• poor auto-updating of labels/values when the other is changed - set your fields to get the property values, and rather change properties than fields if you will use those values

[Sindar]

Where do you see the grips? I tried dragging all over and couldn't get it to work

Keeping track... here, I only have two items and one value is a single line, so it's pretty easy to keep track of which value goes with which item. But, as you can see, the values don't obviously reflect the labels. So, what if I have 20 items? How do I find the right value to edit? Having it side-by-side with delimiters between lines would help immensely

I don't understand your third comment. My issue is that when I change a value or label, it often creates a new item instead of remaining connected to an existing one

[Mario Malic]

Oh, you ment this box, i misunderstood.

If you want to change the Values,Items, it's best to use startupFcn callback, in which you specify the values. In this window, I think newline works (enter button), so values can be like this (my dropdown menu doesn't look the same though) What version do you use?

val1
asdf
probably*crazy%#"$!chars*!#=worktoo

If you mean, by changing the component name such as app.NameDropDown into another one, most of code (if not all) will change accordingly, at least in my case, I use R2020a.

[Sindar]

I'm also in 2020a. Are you in a live script or the app designer (I haven't used it)? I'm not aware of a programmatic way to control these live script control boxes.

Yes, newline separates items. Visually, this isn't helpful when value expressions wrap to new lines. Mechanically, this can be a problem when pasted text is interpreted as multiple lines (even when it is not)

[Mario Malic]

Yikes, I saw dropdown and then immediately thought of AppDesigner, sorry about this.

Answer 15

[Robert]

The biggest frustration is the limits on supported mex compilers, especially for FORTRAN. Mathworks really painted themselves into a corner with exclusive support of Intel Fortran on Mac and Windows.

They should have stuck with GNU compilers or eleminate the restriction and let us decided which compiler works.

Also, why the slow and process of updaing GNU versions supported on Linux?

[dpb]

Amen, brother...particularly to "let us decided which compiler works"

And, they've not left the era of F77 yet, either.

I'd guess they would far prefer to just pull the Fortran support entirely and have been expecting to see it deprecated every release for last few years.

[Michal Kvasnicka]

This problem is really terrible!

MEX support for Fortran is still extremelly important, at least from my point of view. So any kind of Fortran support ending for MEX is really nightmare.

But, the most important things are:

1. MATLAB oficial support mainly the Intel Parallel Studio XE for (C/C++ and Fortran) on Windows platform. GNU compilers support on Windows should be main target for MATLAB (MinGW is now nearly obsolet ... latest version is from 2017??!!)
2. slow updating process of updating GNU compilers version on Linux, which does not correspond to the current state of default GNU compilers version on supported Linux distributions
3. and moreover, terrible situation with supported NVIDIA CUDA Toolkit versions (required by GPU coder and compiled CUDA objects). Matlab supported CUDA Toolkit does not corresponds to the required GCC versions on many recent LTS Linux distributions

So finaly, the TMW support always responds that external projects (GNU, NVIDIA CUDA, Intel Parallel Studio XE) is not under TMW control, but this situation is nearly unacceptable.

Answer 16

[Bruno Luong]

Some time data comes as single, but text just rejects it

>> x=single(0);
>> y=single(0);
>> text(x,y,'Why single is not supported?')
Error using text
First two or three arguments must be numeric doubles.
 

[Rik]

Support for single is intermittent. The documentation for text lists the supported types: double, categorical, datetime, and duration. There isn't any particular reason why singles are not accepted, but most functions will convert to double internally for numeric formats anyway. If I recall correctly sprintf and dec2hex don't do this anymore, but at the very least they used to. For some reason bwdist returns the output as a single, so there are some quirks with data type at times.

Support for non-doubles has gotten better over the years. In Matlab 6.5 (R13, June 2002) you could hardly do anything with the integer data types (not even plus() is defined). As far as I can tell you could only really cast back to double before you could do anything usefull. I have not been able to tell what the point of (u)int64 was in R13. Maybe a veteran user like Jan can educate me on this (I suspect you need a mex wrapper to get all the bits in an int64).

Answer 17

[Luis Ruiz]

Promote parameters to signals in Simulink models.

It should be possible through some kind of mask. At work, we are running through a problem where we need to change model parameters at run time, one solution is to use set_param, but that makes the simulation dreadfully slow.

The opposite (turning a signal to a parameter) is possible using constant blocks and masks.

I read the limitation comes from how parameters are used inside the models, but this functionality will help developers a lot.

Answer 18

[madhan ravi]

If colon operator supports an array input it would be nice:

 A = 1:10;
 A(:) : A(:)*100 % automatically converting each row to cell if number of elements differ

[Walter Roberson]

This would be an incompatible change. At present A:B is defined to be the vector A(1):B(1) and some people rely on that (especially people who use the result of size(variable) as the upper bound, not understanding that size(variable) returns a vector). If A:B were change to create a cell for non-scalar A or B, existing code would fail.

It would also lead to code that was not very intuitive. At the moment you can do things like 1 + (A:B) and that would not be legal if A or B were non-scalar since plus() with a cell argument is not legal.

[madhan ravi]

Ah I see , it could raise many ambiguities. Or there could be an additional argument in the colon() like 'nonuniform' for example.

[Rik]

@Madhan, so you mean something like a shortcut for meshgrid followed by arrayfun? It would be a neat trick to drop on an unsuspecting new user on this forum ;)

[madhan ravi]

Yea Rik , exactly!

Answer 19

[Rub Ron]

That the edges of a grah cannot be sorted.

Answer 20

[Bruno Luong]

scatteredInterpolant miss a 2 C^2 of methods supported by griddata 'cublic' and especially 'v4'.

Answer 21

[Michal Kvasnicka]

Do you really think, that these threads are read by MTW people??? I am not sure!!!

TMW definitely choose the commercial way of its bussines ... so plenty of toolboxes with all whistles and bells, but all using the matlab engine which definitely needs significant development to catch current new trends in computer science.

Just a two examples (from many others):

1. ODEs ... try to compare matlab ODEs capabilities and performance with Julia's wonderful DifferentialEquations.jl. MATLAB shows really terrible performance and flexibility in this case.

2. VPA ... try to compare VPA and Advanpix MCT toolbox. Again, the MATLAB vpa functionality and performance are really terrible. Nice speed benchmark against MAtlab VPA, Julia, Wolfram Mathematica and several Python libraries (mpmath, flint+arb) for extended precision computations. The page is in Japanese but plots and tables are easy to understand.

3. and so on ... and so on ...

I think MATLAB is still a very unique and powerful tool for numerical calculations, but it is definitely losing strength and becoming a monster standing on clay feet.

[Walter Roberson]

Do you really think, that these threads are reading by MTW people??? I am not sure!!!

I know for a fact that these threads are read and considered by Mathworks employees.

[Walter Roberson]

ODEs are not part of the MATLAB engine.

Meanwhile, Mathworks has been working on improving the performance of the MATLAB engine.

I do think they should be improving the performance of the MuPAD engine, perhaps by adding multithreading (I do not know how much work the existing engine would take to make the routines thread-safe.)

Answer 22

[Phong Pham]

My only feeling while using Matlab is purely amazement. Given that it has such a long development time, I am amazed that it is such a poor execuse for an IDE/execution environment, and even amazed that people actually paid for this.

Come on, with all the money people have been paying you, at least make a decent UI with decent color scheme support. Even eclipse, which is free, supports this.

I don't feel the need to mention the lacking of the language and the standard libraries itself as it's likely a legacy thing that you guys either have to keep for legacy support or are too lazy to do anything about. Either way, I feel like I am writing code with both my hands and feets tied and only allowed to use my tongue to type.

I am forced to used this for my course (student license of course), nothing else. Never again.

[Walter Roberson]

Eclipse has the resources of IBM behind it. (I know some of the key people who work on it.)

Answer 23

[Rik]

Comment posted by John in the previous thread:

Matlab should 'update' the new version instead of installing the new version. The reconfiguration is a nighmare because it's done only once a year or so. The extreme example is firefox, which updates once or twice a day. The users don't need to reconfigure anything.

At least matlab should provide a choice with every new version: new installtion or updating on existing version (and keep all configurations as is).

[Rik]

The installer already grabs a lot of settings from the previous release (color scheme e.g.). I was also greeted by a popup from the Add-On Manager asking if I wanted to install the previously installed support packages.

I suppose that other settings (e.g. the path) could be ported as well.

I doubt they will fundamentally change this anywhere in the foreseable future, but what did you have in mind? There are already updates (which are the bugfixes), so renaming the releases (which introduce new features) to updates will be very confusing.

[Sindar]

Additionally, it is often a good idea to keep old versions of Matlab around until you're sure whether the new release breaks anything. Treating it as an update wouldn't make sense.

[Walter Roberson]

The extreme example is firefox, which updates once or twice a day. The users don't need to reconfigure anything.

Every time firefox installs a new Major version, it creates a new User Profile which it does not initialize from the old one. This messes up my careful configuration, and I have to spend the next while fixing it. It's a big nuisance. It does not warn you in advance it is going to happen, and it is not optional.

Answer 24

[Kenn Sebesta]

The number one issue I have with Matlab is the way in which implicit expansion's syntax was implemented. Perhaps there's some incredibly subtle thinking behind why overloading linear algebra operators made sense, but I haven't seen it. It's not that I haven't agreed with the reasoning, it's that I haven't seen any reasoning at all. My recollection is discovering it when someone complained that it wasn't even in the release notes and that it is, in effect, a breaking[*] change.

Issues like https://www.mathworks.com/matlabcentral/answers/318495-deactivation-switch-for-implicit-expansion#comment_699667 show the ease with which the problem arises. It would have been far preferable to have an explicit operator for implicit expansion, such as `@`, e.g. @+, @-, etc...

[*] breaking because it breaks the rules of linear algebra, which is that `a + b` is only valid if both a and b have the same dimension.

[Rik]

I believe I did see it mentioned in the release notes. It also warned that code that relied on an error being triggered by mismatching array dimensions would no longer work as intended. If you want to I can look it up again and find you a link.

[Michal Kvasnicka]

This topic (implicit expansion vs math correctness) was discused here many, many times. Some people were really very angry, but without any impact on TMW developers.

The final result always was: You have to learn to live with this specific feature. Any kind of implicit expansion disabling is very difficult to implement. You must change your programming habits.

So, now I always check very carefully my code to be correct, which is also quite a good practice in general. Moreover, implicit expansion gives to programmers significantly more pros than cons!

[Walter Roberson]

https://www.mathworks.com/help/matlab/release-notes-R2016b.html

R2016b release notes for MATLAB, first entry under the heading "Mathematics"

[Kenn Sebesta]

It was not mentioned in the release notes in the beginning. http://undocumentedmatlab.com/articles/afterthoughts-on-implicit-expansion gives a good description of the, at-the-time, issue with the changelog. Implicit Expansion first went live in 2016a Prerelease, but didn't go gold until 2016b. Moreover, initially TMW didn't draw much if any attention to the fact that this has breaking characteristics. They've since fixed that, but the oversight points out that they didn't really give much consideration to downstream effects.

I think we can conclude the feature roll-out was mishandled, and existing at-large users wer not given the opportunity to weigh in. Something was going on at the time, perhaps a large customer was applying pressure for this feature to be implemented in exactly this way. I don't know that we'll ever know.

What I do know is that it sure looks like the fix is as simple as using a separate operator for implicit expansion. Maybe there's a reason why this wasn't an option, but the easiest thing to believe is that a large customer wanted it this way and TMW doesn't want the public releations boondoggle of saying that out loud.

The implicit expansion booby-traps have been discussed fairly well, but I'll repeat the easiest example here. If you're using a built-in function, which means TMW specifically makes no future guarantees about the returned vector shape, something like norm(a-b) can get you in a ton of trouble. In a nutshell, you can feed Matlab an nx1 vector and get a 1xn vector in return. You'll get a facutally incorrect result from norm() when what you should get is an error.

And It's wholly impractical to sprinkle code with dimension checking every time a Matlab function is called. Especially because code like norm(a-filt(b) becomes impossible to sanity check.

In this context, it's always upsetting to see people push an onous onto the programmer. It's like suggesting that it's okay for a new C compiler to silently fail when there are typos in variable names. Code which violates the rules should fail to run, whether the rules ar strong typing (C/C++) or linear algebra. Changing the rules can have certain advantages, but it comes at a cost. In the case of implicit expansion why not have created a new operator so that there was no need to change the rules? This is the part I simply don't get, and it's the part that implicit expansion apologists conveniently sidestep.

In my case, the cost was dramatically scaling back Matlab usage and switching to Julia. I know this isn't pracitcal for everyone, and I know that I'm not a $$$ customer so I don't have any real power to fix this. I'm simply putting in my vote so that Matlab has useful public feedback.

[Walter Roberson]

You are misreading Yair. Implicit expansion was clearly announced in r2016b -- I was one of the beta testers. What Yair was saying in his blog was that initially there was no explicit compatibility warning in the release notes that announced the feature.

The possibility for compatibility problems was obvious to me at the time. However I did not have any code that depended upon incompatibility generating an error to be automatically fixed up by try/catch, so for me the frustration was not around incompatibility but rather around my expectations that if I got the orientation wrong then the code would break pointing immediately to the problem; I was using the error to debug the code rather than relying on the error to switch my code flow to correct paths.

[Rik]

I don't get why you would need to sprinkle your code with dimension checks. You just need to do that at the start of your function, after which you are the one making sure there aren't any bugs in your code. An invalid input error should (IMHO) occur at the start of your function during input validation, not in the middle. I do agree that it can be annoying if during debugging the error occurs far away from the buggy line of code (as Walter pointed out).

I disagree with your point that it violates algebra rules. The .* syntax isn't a valid algebra syntax. Is your problem with the fact that the meaning of a syntax inside Matlab changed? Or would it have been fine if implicit expansion had been there from day 1?

I'm not sure there is a convenient character that would achieve the same goal as the current system: readability. The @ character is a good candidate, but it may cause more confusion with function handles than it saves by avoiding bsxfun.

[Kenn Sebesta]

@Rik, in algebra a+b is only valid if a & b have identical dimensions. Likewise, A*b is only valid if the number of columns of A is identical to the rows of b. On what basis do you disagree that implicit expansion overloading of + is unallowable by linalg properties?

You rightly point out that .* is not valid algebra syntax and so it can be meant to mean anything convenient. No objections here to anything TMW does.

You might be right about readability, although I personally don't agree that there is a readability problem by knowing that the code author explicitly wanted implicit expansion, instead of wondering each time there is a +-*/ if the author made a mistake. No matter our guesses, it's never been discussed publicly and that's the rub.

"I don't get why you would need to sprinkle your code with dimension checks. You just need to do that at the start of your function, after which you are the one making sure there aren't any bugs in your code."

This is incorrect. You need to do a dimension check anytime control leaves the file. Any call to another function can potentially change the dimension, now or some time in the future. Previously, error trapping could have caught this immediately. Since 2016 it's a silent failure that can live on for years.

@Walter, with the exception of "misreading Yair", I agree and believe we're saying the same thing. Yair noticed it in 2016a Pre-release. At the time, it seems that TMW did not announce this change in any meangingul manner. Quoting him: "What I am concerned about is that I have not seen the new feature highlighted as a potential backward compatibility issue in the documentation or the release notes."

As such, I will stand by my claim that TMW introduced this without meaningful discussion with the community at-large, seemingly oblivious to the fact that there might be meaningful objections as well as useful suggestions for improvement.

[Kenn Sebesta]

Closing thought because I don't want this to devolve into an argument. This change is what frustrates me. It might not frustrate others, because they operate in a different way with different needs from Matlab.

Others may have different pain points, but since the topic at hand is what frustrates us most about Matlab this is where my colleagues and I stand. We're industry professionals and have had four years to grow accustomed to it. We still find that it provides no benefit (to us), and it came at an unacceptably high cost (to us).

I respect that others love this feature, but with all due respect this discussion isn't particularly useful and is a replay of prior discussions. We're not really adding anything new. The thing I'm still missing is why the syntax was done the way it was and I don't think we're going to find it out this way.

[Michal Kvasnicka]

OK ... again the same angry discussion!!! Try to search in "MATLAB answers" for all posts on this topic. Still the same arguments, still the same counter-arguments. But "implicit expansion" is here several years yet and we all live with that without any serious troubles.

Add: In the 2016, when was the "implicit expansion" introduced (2016a) I was one from many who express really big complaints (very similar to Kenn Sebesta express now here). But more clever guys here convinced me, that any kind of special explicit operator (@ character, for example) is not a possible as effective and fully compatible solution. So, what ... ?!

[Star Strider]

Tangentially, I discovered yesterday that the MATLAB Coder does not support automatic implicit expansion. (I do not have Coder, was helping someone who was having problems with ismember. A bsxfun call solved it, once I figured out what the problem was.)

I do not love automatic implicit expansion. However, it’s been a part of MATLAB for four years at this point, and reversing it now would likely break a lot of code. I have not and will not use it in my File Exchange contributions, for compatibility considerations, using bsxfun calls instead.

[Michal Kvasnicka]

@Star Strider Give me ONE example from FEX, where "implicit expansion" broke the well coded MATLAB program!!! The MATLAB Coder is completely different story.

[Star Strider]

Michal Kvasnicka —

All I wrote was that I don’t use automatic explicit expansion in my FEX contributions, since there are many here who have MATLAB versions earlier than R2016b. Assuming automatic explicit expansion in a FEX contribution would not work for them, so I don’t use it.

You are certainly welcome to assume that all MATLAB versions would be able to use automatic implicit expansion if you so desire, and write FEX contributions with that assumption. I don’t, and I won’t.

[Rik]

@Kenn, I don't see why you want to use strict definitions for one parameter, but not the other. I don't see why Matlab syntax should follow algebraic syntax requirements. It is useful if that is the case, but by no means required, as evidenced by .*.

I disagree with your statement that you need a dimension check every time control leaves your file. That is only the case if you don't trust the output. norm will not suddenly start outputting a different shape array on some release. Only if you rely on norm returning an error do you need checks, but my argument is that you shouldn't do that. Unless you're using undocumented features, every API change (using the term a bit loosely here) should be documented.

Any call to any function could not just change the dimension, but also the value (or trigger errors/warnings). If you have that little trust in a function you shouldn't just check the dimensions, but also the output, effectively re-implementing that function.

I can understand why people dislike this, I just don't understand your argument.

(@Michal, I see only 1 person seeming angry. If this thread/discussion frustrates you, feel free to ignore it and take a walk outside. I don't think implicit expansion is worth a high blood pressure 😉. Also, your last question sound like the start of a true Scotsman fallacy.)

[Michal Kvasnicka]

@Rik you are completely wrong ... really :)

[Michal Kvasnicka]

@Star Strider You said: "However, it’s been a part of MATLAB for four years at this point, and reversing it now would likely break a lot of code."

So I ask for any example ... that is all!

[Star Strider]

Michal Kvasnicka — I wasn’t referring specifically to FEX contributions (although it would certainly apply to any FEX contributions that use automatic implicit expansion), only that reverting back to not supporting it would break a lot of code written using it. That’s obvious, so why the flame war?

[Michal Kvasnicka]

@StarRider No flame war at all!!! Just ask for examples, because lot of people mentioned this without any relevant examples.

[Star Strider]

Michal Kvasnicka —

Sigh. Find someone with MATLAB R2016a or earlier (there are still many), and tell them to run code written assuming automatic implicit expansion. Then deal with their frustration when it throws errors. That is your ‘example’!

Stopping here with this, since it is just not worth pursuing.

[Michal Kvasnicka]

@StarRider Very constructive attitude! Please ignore this thread. You just spread irrelevant opinions without any reproducible examples.

[Rik]

What is your issue? Do you doubt people are using implicit expansion in real code? It is tricky to find an example, but I have posted code using it myself on this forum. Can you provide an example of a FEX submission that uses bsxfun? I would consider it a waste of time to search for an example. Why would that make his opinion irrelevant? Do you want me to post a minimal example to the FEX just so we have a link for you?

[Steven Lord]

Folks, please remain professional in this discussion.

I assure you we had quite a bit of discussion inside MathWorks about the potential of breaking existing code by making what once threw an error now work. I raised some of the concerns you (and many others) have raised myself. [Though your choice of @ as part of the operator wouldn't work, as Rik stated it is already used for defining function handles.]

@Rik, in algebra a+b is only valid if a & b have identical dimensions. Likewise, A*b is only valid if the number of columns of A is identical to the rows of b. On what basis do you disagree that implicit expansion overloading of + is unallowable by linalg properties?

Those are the rules of linear algebra you feel MATLAB should obey? MATLAB has never obeyed those rules, at least not strictly. Let's say for the sake of discussion that we were to introduce a way to stop expansion behavior and have MATLAB strictly abide by those rules you've cited. How long do you think it would take to fix your code? And how much code would break due to the increased memory required to create large constant matrices? Yes, it is likely you would need to fix your code. Let's take a look at a simple example with a hypothetical function to disable expansion.

>> disableExpansionBehavior; % this function does not exist

>> A = magic(4);
>> B = A + 1; % Error, A is size [4 4] and 1 is size [1 1]
>> C = 2 * A; % Error, 2 is size [1 1] and A is size [4 4]

>> D = ones(1e5);
>> E = D + 2; % Error, you need a 1e5-by-1e5 matrix of 2's

As for a concrete example of a function that would break (as written) without implicit expansion, the normalize function in MATLAB uses implicit expansion. Normalizing by 'zscore' (the default normalization method) subtracts the mean of an array A from the array then divides by (in the default case) the std.

F = magic(5)
M = mean(F)
S = std(F)

With implicit expansion you get (more or less, modulo some dim inputs and 'omitnan' to handle NaN values) what's in normalize.m.

N1 = (F-M)./S
N2 = normalize(F, 'zscore')

Without you'd need to use bsxfun or repmat as M and S are the same size but neither is the same size as F. If implicit expansion could be toggled on or off (or disabled entirely) normalize would have to test each time it was called whether implicit expansion was enabled and use a different code path (or temporarily enable it) if it wasn't.

[Walter Roberson]

"in algebra a+b is only valid if a & b have identical dimensions. Likewise, A*b is only valid if the number of columns of A is identical to the rows of b."

It is not uncommon to see formulas in which people add a scalar constant to a matrix instead of building a matrix of the constant and adding that.

It is very very common to see formulas in which people multiply a scalar by a vector instead of building a diagonal matrix of appropriate size containing the constant on the diagonal and multiplying that.

MATLAB has supported scalar expansion from very very early on. I would suspect from the original design, but I have not had an opportunity use the original version.

MATLAB has never been a language designed as a linear algebra language specifically. It was instead designed to make some kinds of programming much easier. Purity of linear algebra was never a goal for it : ease of expression of programs was the goal.

[Michal Kvasnicka]

@Rik I just asking for any representative example (< 2016a) where "implicit expansion" break the code, because some people here say it's very likely. That is all ... !!!

[Bruno Luong]

But any code using auto expansion is not backward compatible. Why you need an example for something that is so obvious?

[Walter Roberson]

Rik and Star Strider are talking about the situation where they are writing FEX contributions that they want to be usable by people who are using releases before R2016b. They are not saying that if you had valid R2016a code that because of implicit expansion it will fail in R2016b; they are not saying that any existing FEX contributions stopped working.

However, they would like to be able to turn off the R2016b+ implicit expansion feature so that when they are writing code they are given errors if they accidentally use implicit expansion: they want this to make it easier for them to write code that would work in older releases as well.

Yair, on the other hand, had a client that was counting on the error being generated, and starting having problems because the error was no longer being generated.

I would not have written code the way that Yair's client did, but the problem was real for them.

[Bruno Luong]

Why do you refer to Yair? The thread is started by Keen Sebesta.

[Walter Roberson]

Yair reference is in the comments above, https://www.mathworks.com/matlabcentral/answers/556024-what-frustrates-you-about-matlab-2#comment_1047391

[Michal Kvasnicka]

@Bruno Luong No ... I am asking for example of well coded MATLAB program (<R2016a), but on >=R2016a does not work, due to the "implicit expansion". Kenn Sebesta and StarRider mentioned here the fact, that "implicit expansion" break the older codes, so I would like to see them.

[Walter Roberson]

Star Strider specifically wrote,

"All I wrote was that I don’t use automatic explicit expansion in my FEX contributions, since there are many here who have MATLAB versions earlier than R2016b. Assuming automatic explicit expansion in a FEX contribution would not work for them, so I don’t use it. "

That was not a statement that old code broke when brought into R2016b: it is a statement that new code written with implicit expansion breaks when used with releases older than R2016b, and that Star Strider deliberately makes his code backwards compatible for earlier releases because in his experience there are still enough people using earlier releases to make the effort worth-while.

[Bruno Luong]

Just to be in the same line: Auto expansion breaks backward compatibility but NOT forward compatibility.

(Well written) Code written before 2016b continues to work.

The only issue people complain is some buggy code that operates on non-identical size arrays might no longer throw an error. But come on, Who care about compatibility of buggy code?

[Michal Kvasnicka]

Very well spoken ... so, there is practically no reason for any complains on "implicit expansion", because backward compatibility is not the real issue!!! People which does not like auto expansion can still use old constructs to keep backward compatibility.

Every known examples of the <R2016b MATLAB codes where auto expansion cause "problems" are buggy or not well written.

[Bruno Luong]

And the only example that I have seen is

norm(vcol + v_unintended_row)

People who makes such mistake (or the opposite) gets quite angry with MATLAB auto-expansion for some reason (well I guess they spend a big chunk of time before figure it out the silent bug).

[Michal Kvasnicka]

Yes, because the function norm() is defined for both the vector and the matrix and always produce scalar output. In principle, every functions with this input/output specification are possible candidates for complains.

[Paul]

Here are some other examples ...

size(vcol + v_unintended_row)
ndims(vcol + v_unintended_row)
max(svd(vcol + v_unintended_row))

Answer 25

[Eric Bender]

I've created an enumeration class by use of the following command:

Simulink.defineIntEnumType('epb_parkbrakeswitch_SL_T','PB_SWITCH_NEUTRAL','PB_SWITCH_UP','PB_SWITCH_DOWN'},[0,1,2],'AddClassNameToEnumNames',true,'HeaderFile','Rte_Type.h','DataScope','Exported');

I have workspace items loaded that make use of this class. I want to save my workspace to a MAT file which will also include this enum class information. I don't currently see that this is possible. Our company's system team doesn't want separate M-FIles for each class but would like it all contained in one file. Currently I'm accomplishing this by have an M-File with this enumeration defintion at the top followed by the variable usages of it. This works, however some of the project's M-File sizes are getting pretty large and it takes awhile to save/load as an M-File. Wish there was a way for enum class defintions to be able to be saved in a MAT file, much faster to load and save.

Answer 26

[Bruno Luong]

The camorbit/camlight (camera toolbar) that makes the 3D graphic rotation turns forever when I swing with the mouse.

It's fun to see this gadget once or twice but if some calculation is going in parallel, this is NOT desirable that some animation takes a hand on the runing thread, and there is not obviousway to disable this feature beside overloading the camlight.m

Answer 27

[Bruno Luong]

MATLAB startup accelerator.

I just don't like my computer being polluted by some services installed in the task scheduler. I prefer it''s OFF by default. More and more people have SSD in the computer, the accelerator has no visible effect even when it's on.

Answer 28

[per isakson]

It frustrates me that

enumeration
events
methods
properties

are not reserved keywords (in R2018b).

The statement

methods = clazz.MethodList;

is legal!

Try this

%%
clearvars
%%
try
    properties = 1;
catch me
    keyboard
end
%%
try
    methods = 1;
catch me
    keyboard
end
%%
try
    events = 1;
catch me
    keyboard
end
%%
try
    enumeration = 1;
catch me
    keyboard
end
%%
whos

it displays

  Name             Size            Bytes  Class     Attributes
  enumeration      1x1                 8  double              
  events           1x1                 8  double              
  methods          1x1                 8  double              
  properties       1x1                 8  double              

[Rik]

Also not in R2020b:

%%
clearvars
%%
try
    properties = 1;
catch me
    keyboard
end
%%
try
    methods = 1;
catch me
    keyboard
end
%%
try
    events = 1;
catch me
    keyboard
end
%%
try
    enumeration = 1;
catch me
    keyboard
end
%%
whos

  Name             Size            Bytes  Class     Attributes

  enumeration      1x1                 8  double              
  events           1x1                 8  double              
  methods          1x1                 8  double              
  properties       1x1                 8  double              

[Steven Lord]

Those keywords are only keywords when used inside a classdef file, this is true. They are also functions that help you gather information about the aspect of an object defined by using the corresponding keyword in the classdef file.

There is long precedent for having a keyword that's only a keyword in certain contexts.

x = 1:7;
y = x.^2;
y(end) % 49

for k = 1:numel(x)
    fprintf("%d^2 is %d.\n", x(k), y(k))
end

One of those uses of end is hightlighted as a keyword. One isn't.

[per isakson]

Yes, but

>> end = 17;
 end = 17;
 ↑
Error: Illegal use of reserved keyword "end".

I like this behavior better.

Answer 29