Results for
I wanted to turn a Markdown nested list of text labels:
- A
- B
- C
- D
- G
- H
- E
- F
- Q
into a directed graph, like this:
Here is my blog post with some related tips for doing this, including text I/O, text processing with patterns, and directed graph operations and visualization.
In 2019, I wrote a MATLAB Central blog post called "The tool builder's gene (or how to get a job at MathWorks)." In it, I explained my personal theory of a characteristic of some engineers that is key for becoming successful software developers at MathWorks.
I just shared this essay on my personal blog, along with a couple of updates.
Over the last 5 years or so, the highest-traffic post on my MATLAB Central image processing blog was not actually about image processing; it was about changing the default line thickness in plots.
Now I have written about some other MATLAB plotting behavior that I have recently changed to suit my own preferences. See this new blog post.
Here is a standard MATLAB plot:
x = 0:pi/100:2*pi;
y1 = sin(x);
y2 = cos(x);
plot(x,y1,x,y2)
I don't like some aspects of this plot, and so I have put the following code into my startup file.
set(groot,"DefaultLineLineWidth",2)
set(groot,"DefaultAxesXLimitMethod","padded")
set(groot,"DefaultAxesYLimitMethod","padded")
set(groot,"DefaultAxesZLimitMethod","padded")
set(groot,"DefaultAxesXGrid","on")
set(groot,"DefaultAxesYGrid","on")
set(groot,"DefaultAxesZGrid","on")
With those defaults changed, here is my preferred appearance:
plot(x,y1,x,y2)
General observations on practical implementation issues regarding add-on versioning
I am making updates to one of my File Exchange add-ons, and the updates will require an updated version of another add-on. The state of versioning for add-ons seems to be a bit of a mess.
First, there are several sources of truth for an add-on’s version:
- The GitHub release version, which gets mirrored to the File Exchange version
- The ToolboxVersion property of toolboxOptions (for an add-on packaged as a toolbox)
- The version in the Contents.m file (if there is one)
Then, there is the question of how to check the version of an installed add-on. You can call matlab.addon.installedAddons, which returns a table. Then you need to inspect the table to see if a particular add-on is present, if it is enabled, and get the version number.
If you can get the version number this way, then you need some code to compare two semantic version numbers (of the form “3.1.4”). I’m not aware of a documented MATLAB function for this. The verLessThan function takes a toolbox name and a version; it doesn’t help you with comparing two versions.
If add-on files were downloaded directly and added to the MATLAB search path manually, instead of using the .mtlbx installer file, the add-on won’t be listed in the table returned by matlab.addon.installedAddon. You’d have to call ver to get the version number from the Contents.m file (if there is one).
Frankly, I don’t want to write any of this code. It would take too long, be challenging to test, and likely be fragile.
Instead, I think I will write some sort of “capabilities” utility function for the add-on. This function will be used to query the presence of needed capabilities. There will still be a slight coding hassle—the client add-on will need to call the capabilities utility function in a try-catch, because earlier versions of the add-on will not have that utility function.
I also posted this over at Harmonic Notes
In one of my MATLAB projects, I want to add a button to an existing axes toolbar. The function for doing this is axtoolbarbtn:
axtoolbarbtn(tb,style,Name=Value)
However, I have found that the existing interfaces and behavior make it quite awkward to accomplish this task.
Here are my observations.
Adding a Button to the Default Axes Toolbar Is Unsupported
plot(1:10)
ax = gca;
tb = ax.Toolbar
Calling axtoolbarbtn on ax results in an error:
>> axtoolbarbtn(tb,"state")
Error using axtoolbarbtn (line 77)
Modifying the default axes toolbar is not supported.
Default Axes Toolbar Can't Be Distinguished from an Empty Toolbar
The Children property of the default axes toolbar is empty. Thus, it appears programmatically to have no buttons, just like an empty toolbar created by axtoolbar.
cla
plot(1:10)
ax = gca;
tb = ax.Toolbar;
tb.Children
ans = 0x0 empty GraphicsPlaceholder array.
tb2 = axtoolbar(ax);
tb2.Children
ans = 0x0 empty GraphicsPlaceholder array.
A Workaround
An empty axes toolbar seems to have no use except to initalize a toolbar before immediately adding buttons to it. Therefore, it seems reasonable to assume that an axes toolbar that appears to be empty is really the default toolbar. While we can't add buttons to the default axes toolbar, we can create a new toolbar that has all the same buttons as the default one, using axtoolbar("default"). And then we can add buttons to the new toolbar.
That observation leads to this workaround:
tb = ax.Toolbar;
if isempty(tb.Children)
% Assume tb is the default axes toolbar. Recreate
% it with the default buttons so that we can add a new
% button.
tb = axtoolbar(ax,"default");
end
btn = axtoolbarbtn(tb);
% Then set up the button as desired (icon, callback,
% etc.) by setting its properties.
As workarounds go, it's not horrible. It just seems a shame to have to delete and then recreate a toolbar just to be able to add a button to it.
The worst part about the workaround is that it is so not obvious. It took me a long time of experimentation to figure it out, including briefly giving it up as seemingly impossible.
The documentation for axtoolbarbtn avoids the issue. The most obvious example to write for axtoolbarbtn would be the first thing every user of it will try: add a toolbar button to the toolbar that gets created automatically in every call to plot. The doc page doesn't include that example, of course, because it wouldn't work.
My Request
I like the axes toolbar concept and the axes interactivity that it promotes, and I think the programming interface design is mostly effective. My request to MathWorks is to modify this interface to smooth out the behavior discontinuity of the default axes toolbar, with an eye towards satisfying (and documenting) the general use case that I've described here.
One possible function design solution is to make the default axes toolbar look and behave like the toolbar created by axtoolbar("default"), so that it has Children and so it is modifiable.
I just published a blog post called "The Story of TIMEIT." I've been thinking about writing something like this ever since Mike Croucher's tic/toc blog post last spring.
There were a lot of opinions about TIMEIT expressed in the comments of that blog post, including some of mine.
My blog post today gives a more full history of the function, its design goals, and how it works. I thought it might prompt more discussion, so I'm creating this thread as a place for it.
If you are an interested user of TIMEIT, feel free to weigh in here with your thoughts. Perhaps the thread will influence MathWorks regarding what to do with TIMEIT, or with related performance measurement capabilities.
Speaking as someone with 31+ years of experience developing and using imshow, I want to advocate for retiring and replacing it.
The function imshow has behaviors and defaults that were appropriate for the MATLAB and computer monitors of the 1990s, but which are not the best choice for most image display situations in today's MATLAB. Also, the 31 years have not been kind to the imshow code base. It is a glitchy, hard-to-maintain monster.
My new File Exchange function, imview, illustrates the kind of changes that I think should be made. The function imview is a much better MATLAB graphics citizen and produces higher quality image display by default, and it dispenses with the whole fraught business of trying to resize the containing figure. Although this is an initial release that does not yet support all the useful options that imshow does, it does enough that I am prepared to stop using imshow in my own work.
The Image Processing Toolbox team has just introduced in R2024b a new image viewer called imageshow, but that image viewer is created in a special-purpose window. It does not satisfy the need for an image display function that works well with the axes and figure objects of the traditional MATLAB graphics system.
I have published a blog post today that describes all this in more detail. I'd be interested to hear what other people think.
Note: Yes, I know there is an Image Processing Toolbox function called imview. That one is a stub for an old toolbox capability that was removed something like 15+ years ago. The only thing the toolbox imview function does now is call error. I have just submitted a support request to MathWorks to remove this old stub.
I wish I knew more about the intended evolution of the capabilities of the function arguments block. I love implementing function syntaxes using this relatively new form, but it doesn't yet handle some function syntax design patterns that I think are valuable and worth keeping.
For example, some functions take an input quantity that can something numeric, or it can be an option string that descriptively names a particular value of that quantity. One example is dateshift(t,"dayofweek",dow), where dow can be an integer from 1 to 7, or it can be one of the option strings "weekday" or "weekend".
Another example is Image Processing Toolbox that take a connectivity specifier as input. The function bwconncomp is one particular case. Connectivity can be specified using certain scalars, certain arrays, or the option string "maximal".
I think this is a worthwhile function design pattern, but I don't think the arguments block validation functionality supports it well (unless you use a lot of extra code that duplicates standard MATLAB behavior, which undermines the value of the arguments block).
MathWorkers - believe me, I know that it is not in your DNA to discuss future features. But would anyone care to offer a hint about directions for the arguments block functionality?
