How to test if a function handle belongs to a particular package?

I have a method that accepts a function handle and then needs to branch depending on whether that function is part of +package1 or +package2. While I can think of some hacks involving parsing the function name and/or package's help text and/or output of dir, is there a better or simpler way?

thanks, -n

Answer 1

[Guillaume]

Probably the simplest would be to parse the output of

functions(yourfunctionhandle)

The file field of that output will contain the full path to the anonymous function, so will contain the package name, if any.

[Naor Movshovitz]

That's already better than my previous hacks. But I'm a little concerned because the functions function seems to be in a grey area uncomfortably close to undocumented, as indicated by the note in the doc. Indeed the behavior doesn't quite match the documentation in my release.

Still, that's the best option so far...

[Steven Lord]

What do you want to do if the function handle is to a function that is not in any package, or is in a package other than package1 or package2?

What you're doing sounds fragile to me. If you tell us why you're trying to do that, we may be able to offer a more robust solution to achieve your end goal.

[Naor Movshovitz]

There are two things I am trying to do. First, I want my function

 find_best(myset, myfunc)

to be able to be called with function handle, myfunc, that points to one of a finite (but growing) collection of functions. And I want it to fail, with an appropriate message, if called with any other function. Rather than specify (and modify) the allowed list explicitly I thought there might be a way to identify handles to functions belonging to a particular package.

Second, the "allowed" list of functions actually comes in two flavors, and I want to branch my find_best function based on those flavors.

To make this (somewhat) concrete, suppose find_best searches for the "best" item from a group, defined either as the item with the highest likelihood score or the lowest loss score. So a function handle to either a loss function or a likelihood function is passed to the search method. I can put a bunch of loss functions in a package +losses and a bunch of likelihood functions in a +likelihoods package. If called with any other function, e.g. find_best(myset, @sin) the search should fail with a useful message.

Certainly, there are many different ways to work around this. For example I can pass the function name as a char vector instead of a function handle and use eval. Or do some creative use of try/catch blocs. Not exactly elegant but then neither is parsing the output of dir...

Any better ideas?

[Guillaume]

Re: documentation. Well, at least it is documented in all versions, so if a change occurs you'll know about it. Saying that, I'm not aware of any major change to the behavior of functions. If you keep with your current design, this is certainly what I'd use.

As Steven says, that design sounds a bit iffy. The way I would implement your requirements would be with functions objects (i.e. classes). I would have an abstract base class from which all functions derive. It is therefore trivial to check whether a function is allowed with isa (or validateattribute) based on its class. To differentiate between the two kind of functions, I would have two additional abstract classes (deriving from the main abstract base class). The whole thing would be something like:

classdef processingfunction 
    methods (Abstract)
        function result = dosomething(this, arg);  %the actual method equivalent to the function handles
    end
end
classdef likelihoodfunction < processingfunction
   %does not need anything extra above the base class. Just a new type
end
classdef lossesfunction < processingfunction
    %does not need anything extra above the base class. Just a new type
end
classdef someactualfunction < likelihoodfunction
    methods
        function result = dosomething(this, arg)
            %actual implementation
            result = arg + 2;
        end
    end
end
function find_best(myset, func)
   validateattributes(fun, {'processingfunction'}, {'scalar'}); %error if func is not derived from processing function
   if isa(func, 'lossesfunction')  %switch behaviour depending of subtype
       result = func.dosomething(1);
   else
       result = func.dosomething(2);
   end
end

There are other advantages to using function objects, such as caching of inputs, precalculating expensive parameters and possibly others. The downside is that OOP in matlab is not always very fast.

[Naor Movshovitz]

Thanks both and yes, I agree that using a class instead of a package would help here. One could even use static methods to make the calling syntax identical to the package syntax avoiding rewrites of the calling functions.

Answer 2

[Image Analyst]

As an example, to find out the folder of the bwdist function in the Image Processing Toolbox:

functionInfo = which('bwdist')
[folder, baseFileNameNoExt, ext] = fileparts(functionInfo)

Here is the file/folder info that is returned:

functionInfo =
    'C:\Program Files\MATLAB\R2017a\toolbox\images\images\bwdist.m'
folder =
    'C:\Program Files\MATLAB\R2017a\toolbox\images\images'
baseFileNameNoExt =
    'bwdist'
ext =
    '.m'

Adapt as needed for your function names.

[Naor Movshovitz]

I didn't know which had this useful return variable. Thank you.

This is a pretty simple solution to my question as posed. For the benefit of future users I want to just comment that using "introspective" functions can sometimes adversely affect performance. I do not know for sure if which is counts as introspective.

[Naor Movshovitz]

Avoid functions that query the state of MATLAB such as inputname, which, whos, exist(var), and dbstack. Run-time introspection is computationally expensive. https://www.mathworks.com/help/matlab/matlab_prog/techniques-for-improving-performance.html

[Guillaume]

I don't see how which is any use to the "question as posed". Since a function handle is just a variable like any other, which will just reply 'variable'.

>> fn = @(x) x+1;
>> functioninfo = which('fn');
functioninfo =

variable

[Image Analyst]

I got the impression that he "needs to branch depending on whether that function is part of +package1 or +package2" so I figured that if he could figure out the folder where that function lives, then he'd know which package it belonged to. That was my thinking.

[Naor Movshovitz]

Guillaume is right. There is maybe potential to use which together with evalin but this seems more brittle than using functions. As discussed under that answer a better approach if possible would be to use a class with static methods.