- Enclose with " for exact match e.g., "uitable report"
- HG2 update
- Improving save performance
- New York City visit, 21-24 May 2013
- Improving fwrite performance
- Setting class property types
- Parsing mlint (Code Analyzer) output
- ishghandle’s undocumented input parameter
- JTattoo look-and-feel demo
- HG’s undocumented parameters interface
- Handle Graphics Behavior
- Matclipse – Eclipse-Matlab interface
- Customizing figure toolbar background
- Getting default HG property values
- Solving a Matlab hang problem
- Desktop (29)
- Figure window (33)
- Guest bloggers (31)
- GUI (91)
- Handle graphics (42)
- Hidden property (31)
- Icons (6)
- Java (113)
- Listeners (16)
- Memory (11)
- Mex (4)
- Presumed future risk (211)
- Semi-documented feature (6)
- Semi-documented function (27)
- Stock Matlab function (83)
- Toolbox (2)
- UI controls (30)
- Uncategorized (7)
- Undocumented feature (99)
- Undocumented function (23)
TagsActiveX Callbacks COM Compiler Desktop Donn Shull Editor FindJObj GUI GUIDE Handle graphics HG2 Hidden property HTML Icons Internal component Java JavaFrame JIDE JMI Joshua Kaplan keyboard Listener Malcolm Lidierth Matt Whitaker Memory Menubar Mex Performance Profiler Pure Matlab schema schema.class schema.prop scribe Semi-documented function Toolbar uicontrol UIInspect uitable uitools uiundo Undocumented feature Undocumented function Undocumented property
- Alexander Mering (1 day 6 hours ago): Hello, I do see problems related to heavy GUI’s. In my GUI, I use 8 Java buttons, 2 CheckboxTrees and overall 8...
- Bukmop (1 day 8 hours ago): Just mentioned typo. There were no angry words
- Yair Altman (1 day 9 hours ago): thanks for the correction, it’s now fixed I have no intention of confusing people, but I am only human – even I...
- Bukmop (1 day 9 hours ago): R2013a is 8.1 … not 8.2! R2013b will probably be 8.2 … please fix to not confuse people
- Yair Altman (1 day 11 hours ago): @Volkmar – here is an alternative that you can use in HG2: done=uicontrol(f,... 'Callback', @(h,e) delete(h));
- Volkmar (1 day 11 hours ago): Works in HG1 only: function close_hg1 f = figure; done=uicontrol(f,... 'Style','Pushbutton',... 'Units','normalized',......
- Yoav (1 day 11 hours ago): Thanks Alexander! The double(hFig) is exactly what I was looking for. I’m heavily using the WindowAPI function from the matlab...
- Yair Altman (1 day 14 hours ago): @Chandrakanth – you need to use the -hgVersion 2 startup switch in your Matlab command-line. feature is not the way
- Chandrakanth (1 day 17 hours ago): Any idea how to enable HG2 on linux/osx versions? Even after setting feature to use hg2, it returns hg1 handles in 8.0 Thanks.
- Malcolm Lidierth (2 days 3 hours ago): @Alexander On Windows, activating DirectX via a java.opts file might (?) improve GUI component performance. The general...
Exactly three years ago, I posted information (here and here) about Matlab’s upcoming new graphics engine, so-called HG2 (Handle Graphics version 2). At the time, I was sure that HG2 was just around the corner. But three years and six releases have passed, Matlab 7 turned into Matlab 8, and HG1 is still in use. I decided that it was time to revisit the latest state of HG2, as reflected in the latest release, R2013a (Matlab 8.1).
In the past few years, development of HG2 has apparently progressed to a stage where most of the kinks were ironed out. The latest HG2 appears to be quite stable, and in my experience most GUI/graphics utilities run as-is, without any need for tweaking. This is good news, which leads me to think that HG2 will be released soon. It is possible that this could happen as early as the upcoming release (R2013b, 8.2) but I have a gut feeling that it will be in R2014a. I also have a gut feeling that MathWorks will name that release 9.0 rather than 8.3, in keeping with its arch-rival Mathematica.
HG2 has improved grid lines, plot anti-aliasing and customizable everything (more on this below). Here’s a simple plot line as it appears in both HG1 and HG2:
hFig = figure('pos',[100,100,300,250]); x = -10:0.1:10; y = 1e7*sin(x)./x; hLine = plot(x,y); box off; grid on; title('HG2 plot');
We can see that MathWorks has invested heavily in improving usability. The graphics are now much more visually appealing than before. A lot of thought has gone into small details such as the plot colors and the axes gray shades. The changes are small when taken separately, but the overall gestalt is striking. HG2 will definitely justify my license maintenance cost.
Two weeks ago I posted an article about improving fwrite‘s performance. fwrite is normally used to store binary data in some custom pre-defined format. But we often don’t need or want to use such low-level functions. Matlab’s built-in save function is an easy and very convenient way to store data in both binary and text formats. This data can later be loaded back into Matlab using the load function. Today’s article will show little-known tricks of improving save‘s performance.
MAT is Matlab’s default data format for the save function. This format is publicly available and adaptors are available for other programming languages (C, C#, Java). Matlab 6 and earlier did not employ automatic data compression; Matlab versions 7.0 (R14) through 7.2 (R2006a) use GZIP compression; Matlab 7.3 (R2006b) and newer can use an HDF5-variant format, which apparently also uses GZIP (level-3) compression, although MathWorks might have done better to pay the license cost of employing SZIP (thanks to Malcolm Lidierth for the clarification). Note that Matlab’s 7.3 format is not a pure HDF5 file, but rather a HDF5 variant that uses an undocumented internal format.
The following table summarizes the available options for saving data using the save function:
|save option||Available since||Data format||Compression||Major functionality|
||R2006b (7.3)||Binary (HDF5)||GZIP||2GB files, class objects|
||R14 (7.0)||Binary (MAT)||GZIP||Compression, Unicode|
||R8 (5.0)||Binary (MAT)||None||N-D arrays, cell arrays, structs|
||All releases||Binary (MAT)||None||2D data|
||All releases||Text||None||Tab/space delimited|
HDF5 uses a generic format to store data of any conceivable type, and has a non-significant storage overhead in order to describe the file’s contents. Moreover, Matlab’s HDF5 implementation does not by default compress non-numeric data (struct and cell arrays). For this reason, HDF5 files are typically larger and slower than non-HDF5 MAT files, especially if the data contains cell arrays or structs. This holds true for both pure-HDF files (saved via the hdf and hdf5 set of functions, for HDF4 and HDF5 formats respectively), and v7.3-format MAT files.
Perhaps for this reason the default preference is for save to use –v7, even on new releases that support –v7.3. This preference can be changed in Matlab’s Preferences/General window (or we could always specify the –v7/-v7.3 switch directly when using save):
I’d like to break the regular flow of weekly articles, to announce that I will visit New York City on May 21-24, to speak at the Matlab Computational Finance Conference (May 23).
I will be very happy to meet you and discuss how I could bring value to your needs, either financial-oriented or not. We can meet at the conference, or elsewhere in NYC on other days: Tuesday (May 21), Wednesday (May 22) or Friday (May 24). If you would like to schedule a meeting, please email me.
Matlab Computational Finance Conference
The Matlab Computational Finance conference is an event that takes place more-or-less annually, in different locations. In 2012 it was held in London; in 2011 it was virtual (online). This year it will be held in New York City on May 23, at the Marriott Marquis hotel, located in midtown (1535 Broadway, next to Times Square).
The free, full-day conference showcases real-world examples of how financial organizations use Matlab to develop risk, trading, investment management, and insurance applications. Highlights include:
- Customer presentations from leading industry practitioners in trading, risk, valuation, portfolio analysis, insurance, and regulatory compliance
- Master class tutorials delivered by senior MathWorks engineers to enhance your understanding of Matlab features and functionality
- Panel discussion with senior Matlab developers
- An opportunity to network, exchange ideas, and discuss challenges and successes with industry peers and Matlab experts
- And naturally, my presentation, slated for 16:50 (I suggest rechecking the agenda close to the conference, to ensure that the time-slot hasn’t changed)
Here is the abstract of my presentation:
MATLAB has traditionally been used for analyzing data off-line, presenting analytic recommendations that were then acted-upon manually. However, MATLAB supports direct interface with data feeds and online brokers, as well as the ability to present sophisticated graphics and user interfaces – all in real time.
This presentation will demonstrate an end-to-end demo trading system in MATLAB, highlighting MATLAB’s potential as a platform of choice. Interactive Brokers will be used to demonstrate live market data feed and account/portfolio input, as well as for sending trading orders to the market. The system’s user interface (GUI) showcases MATLAB’s hidden visualization and interactivity potential, for tracking order executions and charting financial time-series in real-time. Some best-practices for improving real-time performance shall also be discussed.
If you are interested in any aspect of computational finance, you will surely find some interesting presentations at this conference. So if you’re in town, I urge you to attend (hey – it’s free and I hear there’s drinks…). You can register here. If you can’t attend in person, you will be able to see recordings of the proceedings on the conference website some time later.
Readers of this blog are probably aware by now that I am currently writing my second book, MATLAB Performance Tuning (expected publication date: early 2014, CRC Press). During my work on this book, I encounter many surprising aspects of Matlab performance. In many cases these aspects are not un-documented per-se, but are certainly not well known in the Matlab community. So taking some artistic liberty coupled with some influence over this blog’s owner, I’ll mention some of these interesting discoveries here, even if they are not strictly-speaking undocumented.
Today’s post is about the well-known fwrite function, which is used to write binary data to file. In many cases, using fwrite provides the fastest alternative to saving data files (save(…,’-v6′) coming a close second). This function is in fact so low-level, and is used so often, that some readers may be surprised that its default speed can be improved. Today’s article applies equally to the fprintf function, which is used to save data in text format.
Apparently, there are things to be learned even with such standard low-level functions; there’s a deep moral here I guess.
When I wrote about the undocumented aspects of classdef properties half a year ago, I did not expect to learn of another major undocumented aspect in Matlab’s class-object system. last month I discovered the additional undocumented classdef Description and DetailedDescription attributes, and updated that article accordingly. But a few days ago I was pleasantly surprised to read Amro’s comment about an entirely new and undocumented aspect of Matlab MCOS classes.
Amro is a top contributor on StackOverflow, where he frequently answers questions before I even get any subscription notification about them… His answers are generally characterized by a deep technical understanding of Matlab, and I’ve learned quite a lot from him in the past few years. This time was no different.
In a nutshell, Amro found an undocumented way to specify a class object property’s type, in such a way that would prevent accidental setting to an incompatible value. For example, if we have a class with properties Width and Height, we probably want to restrict their possible values to numbers, to prevent setting a string or struct value.
In UDD classes, we can do this easily by setting the property’s DataType meta-property. An easy way to do this is by setting the second argument of the schema.prop function. A detailed explanation was provided here.
We can still do this today, since UDD classes are still supported, side-by-side with the newer MCOS classes. Unfortunately, MCOS does not provide a documented way of specifying the property type as in UDD.
classdef myClass properties myProperty = uint16(23); %# specify default value using correct type end methods function obj = set.myProperty(obj,val) if ~isa(val,'uint16') error('only uint16 values allowed') end %# assign the value obj.myProperty = val; end end end
But it turns out that there’s a much cleaner and simpler solution, provided by Amro:
classdef Packet properties HeaderLength@uint16 PayloadLength@uint16 = uint16(0); PacketType@char end end
Mlint, Matlab’s static code-analysis parser, was written by Stephen Johnson (the original developer of the enormously successful lint parser for C/C++ back in 1977), when he was lured by MathWorks in 2002 to develop a similar tool for Matlab. Since its development (in R14 I believe), and especially since its incorporation in Matlab’s Editor in R2006a (Matlab 7.2), mlint has become a very important tool for reporting potential problems in m-files.
Unfortunately, to this day (R2013a), there is no documented manner of programmatically separating mlint warnings and errors, nor for accessing any of the multitude of features that are readily available in mlint. Naturally, there is (and has always been) an undocumented back door.
From its earliest beginnings, mlint has relied on C code (presumably modeled after lint). For many years mlint relied on a mex file (%matlabroot%/toolbox/matlab/codetools/mlintmex.mex*), which is basically just a wrapper for mlint.dll where the core algorithm resides. In recent releases, mlintmex, just like many other core mex files, was ported into a core Matlab library (libmwbuiltins.dll on Windows). However, the name and interface of the mlintmex function have remained unchanged over the years. Wrapping the core mlintmex function is the mlint m-function (%matlabroot%/toolbox/matlab/codetools/mlint.m) that calls mlintmex internally. In R2011b (Matlab 7.13) its official function name has changed to checkcode, although this was never documented in the release notes for some reason. However, using mlint still works even today. Wrapping all that is the mlintrpt function, which calls mlint/checkcode internally.
The core function mlintmex returns a long string with embedded newlines to separate the messages. For example:
>> str = mlintmex('perfTest.m') str = L 3 (C 1): The value assigned to variable 'A' might be unused. L 4 (C 1): The value assigned to variable 'B' might be unused. L 5 (C 1-3): Variable 'ops', apparently a structure, is changed but the value seems to be unused. L 12 (C 9): This statement (and possibly following ones) cannot be reached. L 53 (C 19-25): The function 'subFunc' might be unused. L 53 (C 27-35): Input argument 'iteration' might be unused. If this is OK, consider replacing it by ~.
Two weeks ago I wrote about Matlab Handle Graphics (HG) undocumented acceptance of structs as input parameter to some plotting functions. Continuing in a related matter, today I expose an undocumented input parameter for HG’s ishghandle function.
ishghandle is a fully-documented built-in Matlab function that returns a
logical flag indicating whether the specified input is a valid HG handle or not. The input could be an invalid handle for several reasons: Perhaps it is not an HG handle in the first place, or perhaps the corresponding HG object has since been deleted (for example, its parent figure window was closed). The usage is very simple:
if ishghandle(myHandle) set(myHandle, ...); end
But what if
myHandle could be any of several possible HG types (e.g., plot line, patch or 3D surface) and our logic depends on the type? Of course, we could always add an extra condition to the logic:
if ishghandle(myHandle) && strcmp(get(h,'type'),'surface') %or: if ishghandle(myHandle) && isa(handle(h),'surface') set(myHandle, ...); end
There’s an undocumented alternative: we can simply specify the expected type as a second input argument to ishghandle. This is in fact the simplest and fastest alternative:
if ishghandle(myHandle,'surface') set(myHandle, ...); end
Three years ago, I wrote an article about modifying Matlab’s look-and-feel (L&F, or LnF), using Java’s built-in support for replaceable LnFs. To date, that article has 27 comments by 13 different commenters (plus 20 responses by me), making it the second most active article on this website. I decided to follow up on that article with a demo that shows the effects that different L&Fs have on GUI controls, and a demonstration of the JTattoo library of professional L&Fs.
Today’s article and the demo are based on original work by Karthik Ponudurai, who has written a guest article here about an interesting technique to interface a Java GUI to a Matlab application, a couple of years ago.
Continuing last week’s article on Matlab Handle Graphics’ (HG) undocumented Behavior functionality, today I describe another undocumented aspect of HG. Some of the low-level HG functions, such as line and path receive their input parameters in one of two formats:
- The regular fully-documented P-V pairs format:
line('Marker','*', 'MarkerSize',8, 'MarkerEdgeColor','b', ... 'Color','r', 'XData',1:5, 'YData',3:7)
- An undocumented struct-fields format:
lineprops.Marker = '*'; lineprops.MarkerSize = 15; lineprops.MarkerEdgeColor = 'b'; lineprops.color = 'r'; lineprops.xdata = 1:5; lineprops.ydata = 3:7; line(lineprops)
Matlab’s Handle Graphics (HG) have been around for ages. Still, to this day it contains many hidden gems. Today I discuss HG’s Behavior property, which is a standard undocumented hidden property of all HG objects.
Behavior is not normally updated directly (although there is absolutely nothing to prevent this), but rather via the semi-documented built-in accessor functions hggetbehavior and hgaddbehavior. This manner of accessing Behavior is similar to its undocumented sibling property ApplicationData, which is accessed by the corresponding getappdata and setappdata functions.
Using HB behaviors
hggetbehavior with no input args displays a list of all pre-installed HG behaviors:
>> hggetbehavior Behavior Object Name Target Handle -------------------------------------------- 'Plotedit'...................Any Graphics Object 'Print'......................Any Graphics Object 'Zoom'.......................Axes 'Pan'........................Axes 'Rotate3d'...................Axes 'DataCursor'.................Axes and Axes Children 'MCodeGeneration'............Axes and Axes Children 'DataDescriptor'.............Axes and Axes Children 'PlotTools'..................Any graphics object 'Linked'.....................Any graphics object 'Brush'......................Any graphics object