A function I want to implement needs to know whether the current version of MATLAB is at least as recent as R2014a.
Is there a robust, supported way to perform this check?
(With "robust, supported" I mean to say that I'm not interested in fragile hacks such as parsing the string returned by version, etc.)
BTW, in this case, the reason I want this check is to know that I can use the function matlab.lang.makeUniqueStrings. If there were a robust, supported way to check for the availability of this function, I'd use it instead of testing that the current MATLAB is recent enough. Unfortunately, there doesn't seem to be such a check: exist returns false to every variant I can come up for the name of this function. Again, I can think of fragile hacks to mimic a proper test (e.g. which('matlab.lang.makeUniqueStrings')), but they're hardly better than the version-testing hacks I alluded to above.
The best solution I have found is to run the command using matlab.lang.makeUniqueStrings within a try-catch block. This is still a fragile hack, because MATLAB does not offer a robust, built-in way to catch specific exceptions!
IOW, it's all about choosing the least awful hack. Testing that the current version is recent enough (even if this test is a fragile hack) at least has the virtue of being general enough to stick in some function, and at least contain the proliferation of fragile, hacky code.
I would use the verLessThan function:
verLessThan('matlab', '8.3')
This will return true (1) if the current version you are using is older than 8.3 (R2014a) and false (0) otherwise. No string parsing required.
You could then use it like so:
if ~verLessThan('matlab', '8.3')
% Run code using matlab.lang.makeUniqueStrings
end
If you only need to care about fairly recent versions, use the verLessThan command. However, verLessThan was introduced in about 2006a or so; if you need to support versions older than that, you will need to use the output of the version command.
Alternatively, you can robustly test for the existence of matlab.lang.makeUniqueStrings. Firstly, use m = meta.package.fromName('matlab.lang') to retrieve a meta.package object referring to the package. If m is empty, the package does not exist. Assuming m is not empty, check the FunctionList property of m to see whether makeUniqueStrings is present. (There's also a ClassList property as well).
Finally, MATLAB does offer a way to catch specific exceptions. Instead of a simple catch, use catch myError. The variable myError will be an object of type MException, available within the catch block. You can test the identifier and message properties of the exception, and handle different exceptions appropriately, including rethrowing unhandled ones.
You may use MATLAB command version for your test -
['Release R' version('-release')]
Sample run -
>> ['Release R' version('-release')]
ans =
Release R2012a
Check if your MATLAB version is the recent one (R2014a) -
strcmp (version('-release'),'R2014a')
The above command would return 1 if it's a recent version, otherwise returns 0.
The best way is to use the version command, and parse the string appropriately.
[v d] = version
Take a look at the output from R2014a, and set your values appropriately.
An example of what Sam meant:
try
%// call to matlab.lang.makeUniqueStrings
catch ME
%// (use regexp here to include support for Octave)
if strcmpi(ME.identifier, 'MATLAB:undefinedVarOrClass')
error('yourFcn:someID',...
'matlab.lang.makeUniqueStrings is not supported on your version of MATLAB.');
else
throw(ME);
end
end
Robust until The MathWorks changes the ID string.
As a final remark: checking for features is not sufficient: what if The MathWorks decides to change the function signature? Or the output argument list? Or ..?
There is no really robust method in a language that is itself not robust. Be as robust as the language allows you, but no more.
Testing for version number is barely a good idea. You should always check for features, and never for versions, if you really want robustness (and at the same time portability).
What will happen if one of the features you need is removed from a future version of Matlab? Or the way it works changes? (this is far more common than one would expect). Or if someone wants to use your code in a Matlab compatible system that does have the features your code requires?
There are some autoconf macros related to Matlab around (although I have never used one). Or you can write your own simply checks in Matlab language.
Related
I'm writing a set of functions that will be used by colleagues who use older versions of MATLAB (2015a/2015b). In one of my functions I use contains() which was only introduced in 2016b and is thus not backward compatible. I'd like to provide a workaround but I'm not quite sure how to go about this. The particular issue that I'm dealing with is as follows:
files = {'/some/path/sub001file','/some/path/sub002file','/some/path/sub003file'};
subjects = {'sub001','sub003'};
files = files(contains(files,subjects))
I'm looking for a way to replace the third line with one that will run on MATLAB2015a and later, and provides identical output. As an aside, since this is a rather small operation the readability of the code is more important than computational efficiency.
It's a bit convoluted, but the following will work,
idx = cellfun(#(c)~all(cellfun(#(d)isempty(strfind(c,d)),subjects)),files);
files = files(idx);
I'm using some third-party package on MATLAB for data analysis. It was compiled using C#, but by default it displayed the results. I want to suppress this display, but should modify the C codes to achieve this. As I'm not familiar with C# and thus it troubles me to re-compile the modified codes, I wonder whether there is a general way to suppress the display in MATLAB as it has provided a way for each built-in function.
Edit:
#bushmills is correct. The function evalc suggested in this thread works. But it can significantly slow down the computation. Is there a better way, for example, declare warning('off',msgid) at the beginning, to suppress display in current function?
Thanks.
I made a code that solve a Mixed Integer Linear Problem (MILP). In order to be as fast as possible, my code is using Cplex functions to solve the MILP, cplexmilp and cplexoptimset.
The only thing I set on cplexoptimset is:
options =cplexoptimset ('Display','off');
And than I run:
x = cplexmilp(var1,var2,var3,var4,var5,var6,var7,var8,var9,var10,var11,var12,options)
When I run the code, I receive the warning:
Warning: The function 'cplexlink1261' returned an mxArray with non-temporary scope
In cplexoptimset/secCplexOptions
In cplexoptimset /setCplexOptions
In cplexoptimset
In cplexoptimset
In myfunction
Nevertheless, after this warning, the code keep running, and it provides me results that seems reasonable.
I surfed the internet looking for an answer, and I found that the reason may be that my Matlab version, 2015b, is not supported for cplex.
Therefore, my question is: can I still trust the results I get from the function? My solution is a binary vector of thousands of variables, so I cannot actually check. Nevertheless, I noticed that other results derived from the code are similar to results I recorded before using the cplexmilpfunction.
I surfed the internet looking for an answer, and I found that the reason may be that my Matlab version, 2015b, is not supported for cplex.
Yes, that is correct; your version of MATLAB is not supported. See the Detailed system requirements for your version of CPLEX (presumably 12.6.1).
Therefore, my question is: can I still trust the results I get from the function?
It's not supported, so it's not tested. Use it at your own risk. If you want to be sure of your results, then use a supported version of MATLAB. I know that is not a very satisfying answer, but it is probably the best you'll get.
It looks like it may be possible to disable the warning (as shown here), but that doesn't change anything.
How to find out about a particular function or class in which version of Matlab/toolbox it was first introduced? I know I can look through all Release Notes, or Google can help sometime, but is there any better way?
Ditto Jonas ... there is no version history for specific functions.
One other thing you can do (if you didn't know this already) is, in your current version of Matlab, to check the value of exist('func'), where func is the name of the MATLAB function. The value this returns for matlab functions is 2, and for built-in functions it's 5.
If you're going for compatibility in your scripts, I would put a condition to check for that function existence before you use it. Otherwise, if you have multiple versions of MATLAB you can run a script to go through all of them or just do it by hand.
There isn't.
Except, if the place you work at has an active service contract with The MathWorks, you can send a service request and have them do the searching for you (be prepared to argue a bit if they just tell you to google the answer yorself). I do that from time to time in the hope that they'll eventually update the documentation.
How would you define "unwanted code"?
Edit:
IMHO, Any code member with 0 active calling members (checked recursively) is unwanted code. (functions, methods, properties, variables are members)
Here's my definition of unwanted code:
A code that does not execute is a dead weight. (Unless it's a [malicious] payload for your actual code, but that's another story :-))
A code that repeats multiple times is increasing the cost of the product.
A code that cannot be regression tested is increasing the cost of the product as well.
You can either remove such code or refactor it, but you don't want to keep it as it is around.
0 active calls and no possibility of use in near future. And I prefer to never comment out anything in case I need for it later since I use SVN (source control).
Like you said in the other thread, code that is not used anywhere at all is pretty much unwanted. As for how to find it I'd suggest FindBugs or CheckStyle if you were using Java, for example, since these tools check to see if a function is used anywhere and marks it as non-used if it isn't. Very nice for getting rid of unnecessary weight.
Well after shortly thinking about it I came up with these three points:
it can be code that should be refactored
it can be code that is not called any more (leftovers from earlier versions)
it can be code that does not apply to your style-guide and way-of-coding
I bet there is a lot more but, that's how I'd define unwanted code.
In java i'd mark the method or class with #Deprecated.
Any PRIVATE code member with no active calling members (checked recursively). Otherwise you do not know if your code is not used out of your scope analysis.
Some things are already posted but here's another:
Functions that almost do the same thing. (only a small variable change and therefore the whole functions is copy pasted and that variable is changed)
Usually I tell my compiler to be as annoyingly noisy as possible, that picks 60% of stuff that I need to examine. Unused functions that are months old (after checking with the VCS) usually get ousted, unless their author tells me when they'll actually be used. Stuff missing prototypes is also instantly suspect.
I think trying to implement automated house cleaning is like trying to make a USB device that guarantees that you 'safely' play Russian Roulette.
The hardest part to check are components added to the build system, few people notice those and unused kludges are left to gather moss.
Beyond that, I typically WANT the code, I just want its author to refactor it a bit and make their style the same as the rest of the project.
Another helpful tool is doxygen, which does help you (visually) see relations in the source tree.. however, if its set at not extracting static symbols / objects, its not going to be very thorough.