Which standard MATLAB functions do you shadow with your own version, and why?
42 views (last 30 days)
When you have two functions on your MATLAB path with the same name, the function in the directory higher up the path gets called, and therefore shadows the function lower in the path. Generally it is not advisable to shadow standard MATLAB functions, but sometimes you might deliberately choose to do this. Which standard MATLAB functions do you shadow by default, and why?
Matt J on 10 May 2017
Do you shadow any standard MATLAB functions by default, and if so, why?
I do not (except inadvertently). It seems like a risky thing to do. I don't think you can fully anticipate how your over-ride will influence other stock MATLAB mfiles that might call it.
James Tursa on 11 May 2017
I have intentionally shadowed fopen, fread, fwrite, fclose before. Options that would read/write VAX binary format numbers were inexplicably removed from MATLAB (what a needless irritation that was!), rendering working code that I had unusable. Rather than rewriting all of the working original code itself (which still worked in older versions of MATLAB), I wrote shadowing functions that picked off the VAX options and wrapped conversion code around it ... passing through everything else to the MATLAB versions. I put these shadowing functions in a directory that was not on the MATLAB path, so they only get used when I cd to that specific directory and run from there (making the shadowing deliberate and intentional for that run only).
I also often do what IA does and write replacement functions when the supplied functions don't do exactly what I want. E.g., using mex routines to allocate variables quickly (uninit), or typecast variables without making a deep copy (typecastx).
Image Analyst on 10 May 2017
I don't. I make new functions. For example I hate how msgbox() displays a message box and then goes barreling along with your code without waiting for the user to click OK (before they added the 'modal' option), so I made my own but I call it msgboxw() instead of shadowing the built-in msgbox(). I never call the built in msgbox() anymore.
Jan on 11 May 2017
I shadow different functions for different Matlab versions to either increase the speed or the compatibility in forward or backward direction, or the power. Examples:
- edit: Opens a Windows Explorer window, when called with a folder
- filesep, pathsep, ispc: Do not need branches for Windows or Linux, when I ran a Windows computer
- groot: Replies 0 for HG1 Matlab versions, forward compatibility.
- ind2rgb: The original implementation is too slow.
- iscellstr: C-Mex
- ismatrix: Forward compatibility
- rmfield: C-Mex
- typecast: Was slow in older versions, input types limited without need.
- ancestor: Forward compatibility
- isequaln: Forward compatibility
- strread, dataread: Backward compatibility.
Under the historical Matlab 6.5 I've shadowed several arithmetic operations for single, because they either did not work or replied wrong values. I had a mystic function called ME_ also to emulate catch ME:
catch ME_, ME = ME_;
ME_ stored the lasterror struct and added a .cause, stored it persistently and replied it when called with an output. With modern Matlab versions, this function was not included in the path, such that the new functionality way available in both versions.
I store these files in a different folders belonging to each Matlab version I have installed. Then my initialization function includes the needed folde dynamically on top of the path.
I tried to check the protection level of Matt Fig's https://www.mathworks.com/matlabcentral/fileexchange/17288-pass-protect and shadowed strcmp to cheat the P-coded function. Unfortunately I had a typo in the code and was not able to start the editor in consequence. Even shutting down was hard, because I call strcmp in finish.m. This told me to be very careful with shadowing.
Walter Roberson on 11 May 2017
On the rare occasion that I shadow a Mathworks function, I am hacking a third-party toolbox written for an older MATLAB version, and need to adapt some call that was valid in old MATLAB but not in current MATLAB. Or perhaps a call that was formerly made to a third party routine with the same name as a MATLAB function.
My preference in such cases is generally to change the original source, but if the same issue shows up in a whole bunch of places, sometimes it is easiest to provide a shadow function.
To be honest, when I do provide a shadow function, it is not uncommon that the reason is I have noticed that the person I am responding to has difficulty following change instructions, so I am looking for minimal source code changes, to save on frustration in explaining more proper fixes to the person.
The other notable case of using a shadow function is that I am assisting users who are using third-party libsvm, which uses some of the same function names as the Statistics Toolbox interface to SVM does, but with different arguments. Though in that case I am seldom writing the shadow function: just re-arranging my path so that the libsvm version gets called.
David Niles on 10 May 2018
I can think of two off the top of my head.
- log10, so that is compatible with integer data types (e.g., images). I was sick of typing y = log10(double(x)) for nearly every use of the function.
- graythresh, because it uses an 8-bit histogram only, and because it returns a value between 0 and 1 regardless of the scale of the input image. I wanted more control for the first issue because my data have higher bit-depth, and the second issue is just silly. I can't imagine any situation in which I would want a threshold to be on a different scale from the data that I want to use it on.
tommsch on 14 Sep 2021
I shadow (actually wrap, to add extra functionality)
warning (since Matlab occasionally disables all warnings without notice.). Extra funcitonality:
- allow :`warning temp on|off id`
- warn me when all warnings are disable
- store all thrown warnings, not just the last one (as returned by lastwarn).
addpath, path, userpath, dbclear, dbstop,
- because they are very slow and I need to occasionally check whether the debug points or the path has changed.
a lot of overloads for syms,
- because their interface is often different than their counterparts for doubles.