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.
Related
I'm working on a large data analysis that incorporates lots of different elements and hence I make heavy use of external toolboxes and functions from file exchange and github. Adding them all to the path via startup.m is my current working method but I'm running into problems of shadowing function names across toolboxes. I don't want to manually change function names or turn them into packages, since a) it's a lot of work to check for shadowing and find all function calls and more importantly b) I'm often updating the toolboxes via git. Since I'm not the author all my changes would be lost.
Is there programmatic way of packaging the toolboxes to create their own namespaces? (With as little overhead as possible?)
Thanks for the help
You can achieve this. Basic idea is to make all functions in a private folder and have only one entry point visible. This entry point is the only file seeing the toolbox, and at the same time it sees the toolbox function first regardless of the order in the search path.
toolbox/exampleToolbox.m
function varargout=exampleToolbox(fcn,varargin)
fcn=str2func(fcn);
varargout=cell(1,nargout);
[varargout{:}]=fcn(varargin{:});
end
with toolbox/exampleToolbox/private/foo.m beeing an example function.
Now you can call foo(1,2,3) via exampleToolbox('foo',1,2,3)
The same technique could be used generating a class. This way you could use exampleToolbox.foo(1,2,3)
I need to rewrite the linkage function in matlab. Now, as I examine it, I realized there is a method called linkagemex inside of it. But I simply cannot step into this method to see its code. Can anyone help me out with this strange situastion?
function Z= linkage (Y, method, pdistArg, varargin)
Z=linkagemex(Y,method);
PS. I think I am pretty good at learning, but matlab is not so easy to learn. If you have good references to learn it well, feel free to let me know. Thanks very much for your time and attention.
As #m.s. mentions, you've found a call to a MEX function. MEX functions are implemented as C code that is compiled into a function callable by MATLAB.
As you've found, you can't step into this method (as it is compiled C code, not MATLAB code), and you don't have access to the C source code, as it's not supplied with MATLAB.
Normally, you would be at kind of a dead end here. Fortunately, that's not quite the case with linkagemex. You'll notice on line 240 of linkage.m that it actually does a test to see whether linkagemex is present. If it isn't, it instead calls a local subfunction linkageold.
I think you can assume that linkageold does at least roughly the same thing as linkagemex. You may like to test them out with a few suitable input arguments to see if they give the same results. If so, then you should be able to rewrite linkage using the code from linkageold rather than linkagemex.
I'm going to comment more generally, related to your PS. Over the last few days I've been answering a few of your questions - and you do seem like a fast learner. But it's not really that MATLAB is hard to learn - you should realize that what you're attempting (rewriting the clustering behaviour of phytree) is not an easy thing to do for even a very advanced user.
MathWorks write their stuff in a way that makes it (hopefully) easy to use - but not necessarily in a way that makes it easy for users to extend or modify. Sometimes they do things for performance reasons that make it impossible for you to modify, as you've found with linkagemex. In addition, phytree is implemented using an old style of OO programming that is no longer properly documented, so even if you have the code, it's difficult to work out what it even does, unless you happen to have been working with MATLAB for years and remember how the old style worked.
My advice would be that you might find it easier to just implement your own clustering method from scratch, rather than trying to build on top of phytree. There will be a lot of further headaches for you down the road you're on, and mostly what you'll learn is that phytree is implemented in an obscure old-fashioned way. If you take the opportunity to implement your own from scratch, you could instead be learning how to implement things using more modern OO methods, which would be more useful for you in the future.
Your call though, that's just my thoughts. Happy to continue trying to answer questions when I can, if you choose to continue with the phytree route.
You came across a MEX function, which "are dynamically linked subroutines that the MATLAB interpreter loads and executes". Since these subroutines are natively compiled, you cannot step into them. See also the MATLAB documentation about MEX functions.
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.
I have a medium to large size system built in perl, that has been developed during the last 15 years and is built of many scripts and pm files,
and in order to improve the system i need more data, the easiest way as i see it to get this data is to have every function in the code to print out the start and end time to some log so it will be possible the understand what is taking the most time.
however this is an old system and some parts are less maintainable than others and on top of it i need it to be running which means in order to get real data i need it to print this out from production.
what i want to do is to override in some way the function declration to wrap each function start in a line like
NAME start STARTTIME PARAMS
and when it leaves the function
NAME ended STARTTIME PARAMS
does anybody can point me to the right direction?
Thanks
Take a look at Devel::NYTProf. It can profile the amount of time that all of your subs are taking (and do a lot more). It doesn't involve a lot of messy code modification; instead you just run your script with it:
perl -d:NYTProf your_script.pl
Previous answers are spot on (I especially recommend Devel::NYTProf). However, a more general technique you could apply in general to gather data about your subroutines' behaviour is fiddling with the symbol table, "appending" (or prepending) code to the actual sub's code.
A couple of pointers:
In Perl, can I call a method before executing every function in a package? (this answer shows a code example you could adapt to your particular situation)
Hook::LexWrap is a module that lets you augment subroutine behaviour in several ways, without touching the original code
HTH
sounds like you need to use a profiler
http://www.perl.org/about/whitepapers/perl-profiling.html
Perl profilers usually have a huge impact on the program performance, so using them in production may not be a great idea.
You can try Devel::ContinuousProfiler that claims to have very low impact (I myself have never used it, just discovered it this morning!)
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.