Not that I know of. You might use the link on the right to request an enhancement with technical support.

–Loren

Is there a way to get around that limitation?
much thanks,
-David

function outdata=movavg(indata,varargin)
%Smooths indata with a boxcar windowed moving average

p=inputParser;

p.addRequired('indata',@isnumeric);
p.addParamValue('wind_size',[],@isnumeric);

p.parse(indata,varargin{:});

if isempty(p.Results.wind_size)
    wind_size=round(length(indata)/20);
else
    wind_size=p.Results.wind_size;
end

if wind_size<1,
   wind_size=1;
end

n_outdata=length(indata)-wind_size+1;
outdata=zeros(1,n_outdata);
for a=1:n_outdata,
    outdata(a)=mean(indata(a:a+wind_size-1));
end

Thanks for the write-up. In my opinion, inputting/outputting variables to a function is the bane of coding in any language. Everyone has their own opinion on how it should be done, and none of them work all that well apart, let alone together when you integrate code. This is an especially a large problem when using a development coding environment like MATLAB as not much is ever polished when it gets used.

I am pleased to see the inputParser function added to the default framework though. Great step in the right direction for elegant and functional parsing of an input stream! As a user of the Python module pyparsing, I have seen first hand how creating a scheme for your parser can pay dividends on code flexibility, simplicity, and readability.

I suggest you revisit this same exercise using inputParser to put the virtues on the ‘big stage’.

-Matt

Typically I’ll only use varargin for handing options down to a lower-level built-in function, for example if the function I’m writing is basically a wrapper for MATLAB’s plot() function. Then the user can specify line types and colors etc., and I as the programmer don’t have to think about how that would work.

I think I misunderstood your code. I thought it depended on names being the same. Clearly not true.

–Loren

Thanks for replying to my post:

# Loren replied on May 5th, 2009 at 20:17 UTC :

Kent- Your code seems to depend on naming the variables in the caller the same as the names in the actual function definition. Seems a bit fragile for my taste.

–Loren

However, I am unsure about your concern. Perhaps my example was unclear. But to address your point, I have no problem calling such functions with different variable names in the caller function.

Say func1 is defined thus:

function x = func1(y)

if isundefined(’y')
y = 1;
end

x = 2*y;

Then func1 can be called like this:
>>z = 2;
>>func1(z)
ans =
2

Moreover, this function works even if z is empty or absent.

ie:

>>clear z
>>func1(z)
ans =
2

or

>>func1()
ans =
2

So, I can’t see your point about fragility, unless you are concerned about maintaining the order and position of the parameters passed - in which case you have me!. I keep the number of passed parameters <= 6. Nevertheless, I value your perspective, and I would appreciate knowing any further thoughts that you have on this issue.

Cheers!

-Kent

What can I say! That was indeed “counter-intuitive (and undocumented) but true.” I applied a generally true statement to something that turned out to be a special case! Thanks for pointing this out.
I tested this in R2008a and R2008b. The difference is actually an order of magnitude!

R2008a

>> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
>> tic, d=cellfun(’isempty’,c); toc
Elapsed time is 0.024467 seconds.
>> tic, d=cellfun(@isempty,c); toc
Elapsed time is 0.929305 seconds.

R2008b

>> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
>> tic, d=cellfun(’isempty’,c); toc
Elapsed time is 0.014660 seconds.
>> tic, d=cellfun(@isempty,c); toc
Elapsed time is 0.557050 seconds.

(These timings are after some warm up - I didn’t use Steve Edins’ timeit so that the results can be directly compared with what you reported for R2007b.)

-Omid

PS. Yair and Martin-
You’ve both written my name as Omar, which is strange given that the last two letters are totally different!

We could improve cellfun to check function handles to see if they match specified strings. Even then MATLAB would have to be careful in case the user has overridden the built-in version of whatever the string points to.

–Loren


>> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
>> tic, d=cellfun(’isempty’,c); toc
Elapsed time is 0.115583 seconds.
>> tic, d=cellfun(@isempty,c); toc
Elapsed time is 7.493989 seconds.


Now, the obvious solution would be for the internal Matlab code to check for function-handle equality and use the optimized version if possible. Perhaps a future Matlab release will do this. Hint hint MTW? :-)

Yair Altman

I agree about the logical indexing. I was not aware of the issues with the function handle, so thanks for pointing that out!