Until Release 14 (MATLAB 7), feval was the way to evaluate a function handle. By that I mean you might write code something like this:
function y = halfcircle(fun,n) if nargin < 2 n = 20; end y = feval(fun,0:pi/n:pi);
And you would call this function like this:
ys = halfcircle(@sin); yc = halfcircle(@cos);
feval can also be used to evaluate functions when they are specified by their name.
fn = 'sin'; y = feval(fn, 0:pi/3:pi);
It is more direct however to call the function itself instead of passing it to feval:
y = sin(0:pi/3:3);
In Release 14, we removed the need to use feval to evaluate function handles. Instead, they can be evaluated directly. Here's what the halfcircle code might look like in MATLAB 7.
function y = halfcircle(fh,n) if nargin < 2 n = 20; end y = fh(0:pi/n:pi);
So, I was curious recently when I saw some code posted in the MATLAB newsgroup containing a line that looked like this:
files = feval('dir','*.gif');
Does anyone have insight about what distinction a user might have made between the MATLAB function dir and other ones?
Please post your comments and thoughts. I'd love to hear how you think about this.
Comments are closed.
10 CommentsOldest to Newest
Functions, which take strings as input arguments, may be used in command form. Some of these are know as commands in other environments, e.g. DIR in DOS. DIR in Matlab thus becomes not as a Matlab function, but rather a shortcut to DIR of the underlying OS. It is possible to overlook that in Matlab the function form is valid for DIR. The command form doesn’t return an argument. Thus, you can see contructs like “files = feval(‘dir’,’*.gif’);” and “files = evalc( ‘dir *.gif’ );”
Yeah, I think the benefit of usage of the “feval” function is to return a structure argument like the ways described in “More on eval”.
Is the doc for dir not clear perhaps? You can get this structure of output by using dir directly also:
fstr = dir(‘*.gif’)
in the help description it says:
files = dir('directory') returns the list of files in the specified directory (or the current directory, if dirname is not specified) to an m-by-1 structure with the fields: name, date, bytes, isdir.
RTFM. The problem (to some of us) is that we already have mental models of *commands* like DIR, SAVE, and PRINT when we try Matlab for the first time. Our models work well with Matlab when we start using it *interactively*. Our models are so well established that *looking through* the documentation of the commands does not change our models.
To me a problem with the Matlab documentation is that I tend to overlook powerful (added) features of functions because they are “hidden” in the body text of the descriptions and not addressed by the examples.
I am a post graguate student.Studing in master of eectronics science.I currently worked on MATLAB but nobody know about the MATLAB.So please you give me a proper guiedens.
krisna kr tiwari
I’ll agree with Per here: I certainly fall victim to “transparency to documentation” occasionally. But sometimes that’s more of a problem with the user (including myself) that MATLAB shouldn’t have to fix; certainly big things like “Notes For C Programmers” are completely necessary and put up appropriately large red flags for common mental model errors when jumping between C and MATLAB.
However an advantage with MATLAB is that you can browse the source of many MATLAB functions to get a direct view (and a good complement to documentation) of what’s going on under the hood, unless they are builtin, like ‘dir’ :-(.
I’m constantly surprised to find relatively sophisticated MATLAB users who are unfamiliar with this “command/function duality”. A section in the MATLAB documentation describes it clearly, but many people never see it:
I found it was necessary to use feval in order to evaluate a function handle in the MATLAB workspace from within a mex function, using mexCallMATLAB.
In this case, I couldn’t find a way to evaluate the function handle directly. This is the only time I can recall ever having to use feval.
It appears that mexCallMATLAB builds a string from the input arguments and evals it in the caller workspace, which I think it the reason why I had to all feval working with a function handle.
The relevant portions of my code are:
% call mexFEval on function handle, returning 1 arg
% fh is a handle to a nested function
r = mexFEval(fh);
% the mex function has a single line (aside from error checking)
mexCallMATLAB(nlhs, plhs, nrhs, prhs, “feval”);
Yes, I was limiting my thoughts to M-files, not mex-files. For mex-files, I believe you have to call feval with function handles currently.