What is missing from MATLAB #2 - the next decade edition
Rik
on 31 Jul 2020
Latest activity Reply by Robinson Besson
about 17 hours ago
Meta threads have a tendency to grow large. This has happened several times before (the wishlist threads #1 #2 #3 #4 #5, and 'What frustrates you about MATLAB?' #1 and #2).
No wonder that a thread from early 2011 has also kept growing. After just under a decade there are (at time of writing) 119 answers, making the page slow to load and navigate (especially on mobile). So after a friendly nudge; here is a new thread for the things that are missing from Matlab.
Same question: are there things you think should be possible in Matlab, but aren't? What things are possible with software packages similar to Matlab that Matlab would benefit from? (note that you can also submit an enhancement request through support, although I suspect they will be monitoring activity on this thread as well)
What should you post where?
Next Gen threads (#1): features that would break compatibility with previous versions, but would be nice to have
@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)
169 Comments
Might have been requested before : do-while control structures.
There are situation where it make sens to perform the loop's action before testing for it's condition, and in thoses case the do-while structure is more leggible than a while.
E.g. recently I had to pick an element from a list, that matched some condition. So I need to pick an element, then check if it respect the condition, and if needed pick a different element. (yeah, I know I could generate a reduced list containing only valid elements and pick from that ; but it's beside my point here.)
So currently I have two options :
a) repeat the picking instruction :
some_list = 1:10;
i = randi(numel(some_list));
while ~is_valid(some_list(i))
i = randi(numel(some_list));
end
b) introduce some variable
some_list = 1:10;
can_continue = true;
while can_continue
i = randi(numel(some_list));
can_continue = ~is_valid(some_list(i));
end
In my opinion, neither of those are elegant. They can be hard to read if the loop content is particularly large, or the condition complex ; and code repetition makes maintenance harder.
I know it's just syntactic sugar, but it also shouldn't be super hard to implement (in compiled language it could be done throught some pre-compile time macro).
And finaly, I'm not the only one who whish for that control structure :
I'm sure I mentiond this at some point... but it would be useful if you could substitute a logical index for more than one dimension.
For example:
img = imread('flamingos.jpg');
intens = rgb2gray(img);
mask = intens > 128;
newimg = img;
At this point, we would like to be able to use something like
%newimg(mask, 3) = 255 - img(mask, 3);
but that is not going to work, and instead we need to proceed something like
temp = img(:,:,3);
temp(mask) = 255 - temp(mask);
newimg(:,:,3) = temp;
subplot(2,1,1); image(img); title('original');
subplot(2,1,2); image(newimg); title('modified')
Now, there is a way to do it without a temporary variable, but it is ugly...
img = imread('flamingos.jpg');
intens = rgb2gray(img);
mask = intens > 128;
newimg2 = img;
newimg2(find(mask) + 2 * numel(mask)) = 255 - img(find(mask) + 2 * numel(mask));
figure;
subplot(2,1,1); image(newimg2); title('modified -- indexing')
isequal(newimg, newimg2)
An AI copilot feature-option in the IDE, where either matlab has their own model (optimal) with adjustable privacy that users can determine (to avoid possible gdpr etc issues), and/or the capacity to configure the copilot to work with an LLM service of our choice (also possibly run locally).
In the current state of afairs, continuing using an ide with no copilot integration is non-sustainable. Not for the future, for like yesterday. I already feel quite anxious falling behind compared to python users in terms of copilot language-specific support. There is a ton of python stuff out there that LLMs are trained on, and ime existing LLMs are worse in many other languages, including matlab. The direction copilots seem to get is different "specialised experts", and it seems finetuning different models to specific languages each has potential.
It would be great if Mathworks finetuned an LLM, which could, for example, either be some version of GPT3.5/4 that we could then use through an API, or a version of codellama that is (almost) open source that then mathworks itself could provide through an API (as an extra toolbox, or subscription, or whatnot). Or both options (why bet on one horse only?) or something else entirely. Also, it would be great if people who write matlab using other environments like neovim or vs-code had access to that model too. Even better if it is available for people to also run locally, like the codellama derivatives.
Finetuning a model should not be a great deal for a big company like mathworks, people with much less budget do this sort of thing nowadays. Mathworks has access to tons of matlab code they could use, and I cannot see anything putting any great obstacle to that apart from intention. There are a lot of companies and startups right now doing this sort of thing for other languages. But if mathworks does not do that with matlab, I don't know if anybody else will bother with it. So please consider offering something in that direction, because very soon it seems that writing code without option for copilot assistance will not be conceivable.
In some sense, you already deserved so even before.
I wonder if I will get any residuals for the various models that train on the numerous answers I have given? Somehow I suspect not...
When defining Abstract methods on a class, I would like to be able to fix the arguments on the abstract class.
Something like this would be usefull:
classdef AbstractSuperClass
methods (Abstract)
function AbstractMethod(self,input1,input2)
arguments
self
input1 (1,1) double
input2 (1,1) double
end
% no function body because it is abstract
end
end
end
Right now, I always end writing two versions of the same method to avoid the need to copy the arguments validation block to the subclass:
classdef AbstractSuperClass
methods
function Method(self,input1,input2)
arguments
self
input1 (1,1) double
input2 (1,1) double
end
abstract_version_of_method(self,input1,input2)
end
end
methods (Abstract,access=protected)
abstract_version_of_method(self,input1,input2)
end
end
but this feels wrong to do it and results in programming errors because I forget what the input signature of the method is, the above syntax would be more elegant and would allow for checking whether the input signature of the implementation of the method follows the definition in the abstract class.
With the new arguments (output), I would even be able to fix the output type of my abstract function
Oooh, tentative +1 on this. This is something I hadn't even thought of, and I'm not sure what all the implications of doing this in Matlab would be. But it's basically how traditional static OOP languages like Java and C++ work, and there it's obviously the right thing and we just take it for granted. There, the types etc of the input arguments are part of the interface or signature of those methods, and subclasses must conform to them, and that just makes things easy to reason about. (IMHO.)
I wish clearvars had an optional "do-nothing" flag a la the /L switch in CMD XCOPY to display the variable that would be cleared with the given variables list...would let one confirm a wildcard expression didn't accidentally wipe out something wished to have kept; particular with the -except clause.
Oooh, good idea. PowerShell does this for a bunch of their cmdlets like xcopy. I call this a "dry-run" or "what-if" run. I think PowerShell and recent Windows have standardized on the -WhatIf option for this.
Maybe there's a way I've not found, but I wish arrayfun and cellfun would have automagic argument expansion so one could pass other arguments to the anonymous function without having to replicate them manually to match the others. This would add greatly to the convenience in using either; the present working example happens to be building a set of target range expressions to stuff into a cell array that will be written to Excel although that really has nothing to do with the request/enhancement, just happens to be current time was frustrated that there's no way to pass constants to the anonymous functions to allow them to be generalized.
Example:
Building a variably-sized workbook where it is desirable that the sums over a section of the sheet be formulas rather than the current fixed constant value of the data as the sheet will subsequently be modified by hand; the tool is to build the original working pattern by compending various data sources and arranging for the end user...
It boils down to the point at which one has a set of row range indices and a set of columns over which to build the formula and insert into the cell array which is subsequently written to the workbook. That code looks something like
% anonymous function that builds Excel =SUM(r1:r2) expression for given row range, column
xlsSumRange=@(r1,r2,c)strcat('=SUM(',xlsAddr(r1,c),':',xlsAddr(r2,c),')');
% typical use
col=xlsCol2Col('G'); % another internal translation layer of local array position from Excel column
cOut(isTotal,col)=arrayfun(@(r1,r2,c)xlsSumRange(r1,r2,c),RS1,RS2,repmat('G',numel(RS)-1,1),'UniformOutput',0);
col=xlsCol2Col('K'); % another internal translation layer of local array position from Excel column
cOut(isTotal,col)=arrayfun(@(r1,r2,c)xlsSumRange(r1,r2,c),RS1,RS2,repmat('K',numel(RS)-1,1),'UniformOutput',0);
This works, but the expression "repmat('G',numel(RS)-1,1)" needed is really inconvenient and clutters up the code legibility greatly. I've had any number of similar case in the past where an anonymous function is useful shorthand but then to use more than once requires a workaround like the above.
The alternative is to redefine the anonymous function dynamically and embed the constant inside it for the given invocation.
To visualize, an example output for the above for one invocation looks like for the call with column 'G'
K>> arrayfun(@(r1,r2,c)xlsSumRange(r1,r2,c),RS1,RS2,repmat('K',numel(RS)-1,1),'UniformOutput',0);
ans =
3×1 cell array
{'=SUM($G$3:$G$17)' }
{'=SUM($G$22:$G$372)' }
{'=SUM($G$377:$G$414)'}
K>>
The above could be in a loop over the number of columns instead of using the explicit columns, but was part of still rearranging the output file structure at the time...and, haven't taken the time to clean it all up yet...
+1 on this, @dpb. This "implicit scalar expansion for (array|cell)fun args" is a use case I've had occasional cause to want, and haven't been able to figure out a good way to do, except for ditching arrayfun and Functional Programming style and inverting the logic/control-flow to just write a vectorized or "regular Matlab" version of the function I'm trying to do.
In other use cases, as long as I don't care about method-call overhead, I've been able to wrap the value to be expanded in an "infinite copies" array, like this SPAM thing here:
classdef SPAM
% "spam" a value to every element of an infinite virtual array
properties
Value
end
methods
function this = SPAM(x)
this.Value = x;
end
function out = subsref(this, S) %#ok<INUSD>
out = this.Value;
end
end
end
But that doesn't seem to work with cellfun/arrayfun, because it looks like they do an explicit "size(...)" test on their inputs before trying to index in to them.
>> x = magic(3);
>> z = arrayfun(@plus, x, SPAM(420))
Error using arrayfun
All of the input arguments must be of the same size and shape.
Previous inputs had size 3 in dimension 1. Input #3 has size 1
>> spam = SPAM(420);
>> z = NaN(size(x)); for i = 1:numel(z); z(i) = x(i) + spam(i); end
>> z
z =
428 421 426
423 425 427
424 429 422
>>
Can't say I blame Matlab for this, though. I like explicit size-conformity checks; catches bugs more often than it prevents features.
Thanks @Stephen23, @Bruno Luong and @Steven Lord for the feedback and example coding...I'll snag the code snippets and stuff away with the present code in a comment block and come back and revisit when some of the time pressure lessens...
You could avoid the need for 'UniformOutput' by using string arrays. I also changed xlsSumRangeCol to use string concatenation (with +) rather than strcat.
xlsAddr = @(r,c) sprintf("$%c$%d", c, r);
xlsSumRangeCol = @(c) @(r1,r2) "=SUM(" + xlsAddr(r1,c) + ":" + xlsAddr(r2,c) + ")";
c = 'G';
xlsSumRange = xlsSumRangeCol(c);
RS1 = 1:3;
RS2 = RS1+10;
arrayfun(xlsSumRange,RS1,RS2)
Or you could vectorize xlsSumRangeCol to eliminate the need for arrayfun.
xlsSumRangeCol = @(c) @(r1,r2) "=SUM($" + c + "$" + r1 + ":$" + c + "$" + r2 + ")";
xlsSumRange = xlsSumRangeCol(c);
xlsSumRange(RS1, RS2)
Or if you want the range to always be a certain number of elements long:
xlsSumRange1 = @(c, r1, n) "=SUM($" + c + "$" + r1 + ":$" + c + "$" + (r1+n) + ")";
xlsSumRange1(c, RS1, 10)
@dpb The whole point of TMW anymous function design is to be able to call it with only changing variables, and constant variable in the workspace is captured in the context without explicitly entered as input argument. This logic is tailored with arrayfun/cellfun, and other functions that requires function handles as input (fmincon and friends).
Or if you want it properly you could cascade the anonymous functions as following
xlsAddr = @(r,c) sprintf('$%c$%d', c, r);
xlsSumRangeCol = @(c) @(r1,r2)strcat('=SUM(',xlsAddr(r1,c),':',xlsAddr(r2,c),')');
c = 'G';
xlsSumRange = xlsSumRangeCol(c);
RS1 = 1:3;
RS2 = RS1+10;
arrayfun(@(r1,r2)xlsSumRange(r1,r2),RS1,RS2,'UniformOutput',0)
Admitly the 'Uniform' argument does look ugly and for-loop is much more readable.
Possibly, Walter.
In the end I gave up the arrayfun syntax entirely in this application because there are M rows and N ranges per row over which to build a compound Excel range so the number of elements in the argument list isn't the same and the complexity just got to be too much.
So, I ended up reverting to a doubly-nested loop using the direct sprintf() form for each combination and then join'ed them in the end to pass to Excel COM instruction...sometimes we fall into the trap of trying to remove explicit loops too often.
But, I STILL think the idea has merit...there have been a number of times I'd really, really like to have been able to have done.
I wonder if string operations would be faster these days?
xlsSumRange = @(r1,r2)"=SUM(" + xlsAddr(r1,c) + ":" + xlsAddr(r2,c) + ")");
in which case you would not need 'UniformOutput', 0 directly because string arrays are a thing. (On the other hand you cannot store a string array into a scalar location.)
Somehow I developed an aversion to redefining the function to parameterize; I guess on due consideration it would be the way to simplify with current syntax. Thanks for the prod, @Stephen23...but, I still think the suggestion would be a worthwhile extension to the [array/cell]fun syntax.
This just boils down to function parameterization, which is indeed simpler and more efficient:
c = 'G';
xlsSumRange = @(r1,r2)strcat('=SUM(',xlsAddr(r1,c),':',xlsAddr(r2,c),')');
% typical use
col = xlsCol2Col(c);
cOut(isTotal,col) = arrayfun(xlsSumRange,RS1,RS2, 'UniformOutput',0);
Replacing STRCAT with SPRINTF would also be more efficient:
xlsSumRange = @(r1,r2) sprintf('=SUM(%s:%s)',xlsAddr(r1,c),xlsAddr(r2,c));
read/writetable from/to Excel workbooks should be able to return/write the comment (now called something else, I forget what) field and the formula associated with the cell as well as the value. While one can write COM to do so, it then takes either using COM entirely (can be a lot of work) or have to use both high-level and COM on the same file; either of which options isn't ideal. Sure, one could forego Excel entirely since have MATLAB, but unfortunately can't always have what we want in that regards.
One can mung on the old xlsread/write routine and add stuff into it, but it's also kinda' klunky and while more convenient in some ways as compared to writing all COM totally from scratch isn't nearly as convenient as would be a higher-level interface with the other current toolset.
There's a hook to a function call in xlsread although I was never able to get it to work to do either of the above; because the Excel COM object isn't exposed to the function to be able to make direct access from that function.
"matlab coder" toolbox can't produce only one C/C++ file, refer to:
matlab AXES PROPERTIES missing:
I'm going to be a weirdo and say that I would like it if imshow() supported IA and RGBA inputs. I'm probably the only person who ever uses RGBA workflows in MATLAB, but these are wishes we're talking about. I might as well wish for a function that gives me a sandwich.
I already made my own tool for MIMT, but it kind of drives me up the wall to not be able to use all the conveniences I created when answering questions on the forum. I feel like I'm defeating myself.
Probably it breaks compatibility, but it would make functions/operators svd, *, ', .' dealing with n-d arrays similar to pagesvd, pagemtimes, ... followed by appropriated reshape.
Extend the pagexxx with matrix left/right division, lu, qr, chol, eig, etc...
@Adam Not only the floating point rounding can create different numerically result, but what matters even more is that the floating point counts when multiply matrices can be different.
Consider the product
A*B*x
with
- A: p x m,
- B: m x n,
- x: m x 1
with p = 100, n = 100, m = 1000,
It is much cheaper to perform
A*(B*x) than (A*B)*x.
And in general the less operations is carried out, the less round-off has effect on the final result.
Ah, that's the thing I was missing, thanks for clarifying that
@Adam: binary floating point addition and multiplication are not associative:
This means the order matters.
I don't really understand why associativity control is important.
Is the result not the same for both cases?
Maybe I'm missing something.
Good idea
pagemtimes(A,B,C)
User should be able somehow to control the associativity, meaning equivalent to
pagemtimes(A,pagemtimes(B,C))
or
pagemtimes(pagemtimes(A,B),C)
I really find these page functions very usefull. Some usefull additions in my opinion would be:
Have the option to multiply more than two matrices with pagemtimes
I now always end up writing pagemtimes(A,pagemtimes(B,C)). It would be very usefull to be able to write pagemtimes(A,B,C) in the future for the readability of the code.
Paged version of decomposition
The decomposition is also a usefull tool and would be nice to have a page version of it available
Thank you Steve, and also to the dedicated developpers.
We only added one page function in release R2022b. It's not on your list, but you might find pagenorm useful.
Hi Steve, the priority remains in this order to me. Thanks
The pagemldivide, pagemrdivide, and pageinv functions are new as of release R2022a. We also have several other page* functions (including all but one of the items in your top 4 levels, we don't have a pageeig function) as shown in the functions list.
So does your list still start with pageeig or have one of the items at a lower level jumped ahead of it in your prioritization?
Priority in term of usefullness IMO should be
- pagetranspose, pagectranspose
- pagemtimes
- pagemrdivide (pagemldivide can just be a wrapparound), but as mrdivide is based on qr factorization, interm of dev I guess TMW woul need to make dave of pageqr first.
- pagesvd, pageeig
- pageqr, pagelu, pagechol
- pageldl
- pageexpm
- pagehess, pageqz, pageschur
- pageinv, pagetrace, pagedet
You've listed a bunch of functions there. Out of curiosity, if you had to prioritize which additional functions would you like to see get the pagemtimes, pagetranspose, pagectranspose, and pagesvd treatment first? What would be your top say half a dozen?
Being able to access the properties/methods/fields of an object/struct even after indexing into one would be a big deal.
Currently, if you have a struct A, with fields size and count, you could do A. then tab to show the options for the fields. But if you do A(1). you cannot now tab to show the options for the fields. Same with an object. So the discoverability is gone.
I want to be able to index into an object/struct and still have the available fields/properties/methods for that parent show up.
I just tried this on 2020b and hitting tab after A(1). showed the fields.
+1 on this: Currently, if you have a struct A, with fields size and count, you could do A. then tab to show the options for the fields. But if you do A(1). you cannot now tab to show the options for the fields. Same with an object. So the discoverability is gone.
Maintain dimensions when getting a field of a class.
If Data is a 3x2x4 array of objects/structs with a field "foo", then Data.foo should be an 3x2x4 array of the type of "foo". Not a 1x24 array, or is it the other way around.
Yes you are right, now I remember. Always have to do something like "foo = [Data.foo]".
It currently is neither: it's a comma separated list.
for i1=1:3,for i2=1:2,for i3=1:4,s(i1,i2,i3).Data=rand;end,end,end
s.Data
To do something with it you'll have to capture it with [] or {} or a function that allows arbitrary input.
I agree. Makes intuitive sense to me and would be convenient for extracting foo.
Fix the semantics of "clear".
"clear all" does not clear all, but "clear classes" does. Go figure. I want a way to clear classes and only classes.
Clear also cannot clear specific classes in different packages if they have the same name. I.e. pkg1.my_class, and pkg2.my_class. Matlab's package system is broken, but at least some things could be improved.
In the code analyzer, there is no easy way to find what #ok directive controls a particular flagged issue.
(And no overall list of the available #ok directives, at least that I can find. Even the enable/disable messages in preferences don't show them.)
Perhaps the codeIssues function introduced in release R2022b will be of use to you. The CheckID variable in the issues table stored in the codeIssues object is the identifier you'd use in the %#ok pragma to suppress Code Analyzer's reporting of that particular issue.
Maybe I've only looked in the wrong places, but the changes from release to release about what is marked as a warning by mlint are poorly (or not) documented in the release notes.
So there are more things leaving room for improvement regarding this.
I would like imagesc(C) to work with 3 dimensional arrays.
vol 3d v2 in File Exchange.
See also the code I posted in https://www.mathworks.com/matlabcentral/answers/1447449-how-to-draw-a-volxe-size#comment_1728709 about a month ago, which creates voxel cubes (taking care that each one has proper face orientation so normals can be calculated).
The disadvantage of the code I posted is that it builds a cube for each voxel, instead of trying to merge together adjacent voxels to reduce the drawing cost. Drawing one cube for each voxel has advantages if you want to be able to use per-voxel alphadata (since two adjacent cubes with exactly the same "value" attribute might potentially be assigned different alpha.
The code I posted there only draws cubes for "occupied" voxels. Which reduces drawing costs, but leads to questions about the best way to create alpha data -- do you create the alpha data as a cuboid that occupies the full possible space, or do you create the alpha data in a way that maps only to the occupied locations?
Sorry about the name typo.
Since it is a very different goal, why should it have the same name? I'm a firm advocate for the concept that a function should do one Thing. What constitutes a Thing can of course be flexible, but in this case 2D and 3D are different enough that they would require different tools.
Have you looked at the File Exchange for 3D viewers? There are many of them. One might already do what you want. I don't recall any built-in function that will directly do this. The colors are simply based on the current colormap, so that should be easy enough to implement.
Also, next time you use your phone to answer here, double check the spelling of the name of the person you're replying to.
Hi Rik. I would use it as a volumetric viewer as you say. I would pass a 3D array to imagesc (or you can call it something else) and it would be able to plot 3D little cuboids, instead of 2D faces it plots now. The cubes would be colored based on the values stored in the array, in the same way imagesc works now. Maybe I would also use AlphaData to make some of the little cuboids transparent based on what I am interested in.
What should the behavior be? Why aren't you using a dedicated volumetric viewer for volumetric data? And if you're talking about RGB-images, what would be the point of using imagesc instead of image (or the high-level imshow)?
Your TypicalX option for fminunc() (and others?) should be extended beyond usage for gradient evaluation only.
I have used normalized variables for optimization for a long time. By default, I do start with [1,1,...,1] as you do, but for gradient evaluation only. There are many areas where a spread of variables is vast (radiolectronics: kiloohms to nanofarads).
Currently evalin() accepts a context argument (such as 'caller' or 'base' or symengine()), and a character vector that is the command to be executed.
This runs into the same horrors as using eval() .
It is difficult to convince people to give up using eval(); they tend to think that their particular use case makes it necessary (it rarely is!). And the cause is Not Helped At All when we have to say "well, it is true that the closely-related "evalin() is needed sometimes"
It would therefore help if there was a way to do something like evalin() but with a function handle. For example,
evalin('caller', 'whos')
might become something like
evalfcnin('caller', @whos)
To be honest, I do not know how this would work in practice, considering that functions need their own workspace to execute in. Maybe some of the technology behind shared variables and nested functions could be used, so that the function could have read/write access to the designated function workspace and yet still be able to have its own private variables.
Sometimes I want to be able to get a look at persistent variables in a function that is not the caller; I have never found a hint that is possible. But the existence of persistent variables that go away when you "clear" the function, implies that each parsed function already has some kind of workspace associated with it. And sometimes it seems to me that it would be useful if you were able to get a referene to that workspace and tell a function to execute using that workspace. Something that might look like
evalinWorkSpace( matlab.workspace.getinstance.caller, @whos)
Having workspaces as accessible objects leads to some interesting possibilities about saving and restoring state, such as for the purpose of recovering from power failures; it also heads towards possibilities such as co-routines.
