AVOID GLOBAL VARIABLES. They will not improve your code. Intead they will make it difficult as hell to debug your code when there is a problem.
Next, don't just store all of your arguments in a cell array. That would simply force you to remember what parameter lies in ARGS{7}, etc. This is a recipe for buggy code, and certainly not readable code that can be maintained easily.
The various suggestions I see are all good ideas. Another idea is to use preferences, thus setpref and getpref. I use this sometimes when I want to set some general behavior for a function. Other things are property/value pairs, and structures. You can even combine all of these things in various ways. Let me give a few examples:
The examples I'll offer are my HPF toolbox, fmincon, and my SLM toolbox. How are each of these tools different?
For example, fmincon is a tool that has quite a few arguments, most of which are not used at least some of the time. The basic calling sequence for fmincon is something like this:
X = fmincon(FUN,X0,A,B,Aeq,Beq,LB,UB,NONLCON,OPTIONS)
Now much of the time, you may want to call fmincon, but only have a set of linear equality constraints on the objective. In that case, you call it like:
X = fmincon(FUN,X0,[],[],Aeq,Beq);
Or, if you have only bound constraints, then you need to write it as:
X = fmincon(FUN,X0,[],[],[],[],lb,ub);
And you need to know how many sets of empty brackets to put in there. This can be a confusing way to interact with the tool.
So an alternative way to have written fmincon might be to have only three arguments.
X = fmincon(FUN,X0,params);
Here params would be a structure, containing every possible piece of information fmincon would need. Thus if there are only upper and lower bounds on the problem, then we would have
params.lb = [1 2 3];
params.ub = [2 3 5];
If there were equality or inequality constraints on the problem, then params would have corresponding fields to supply them.
(Yes, the optimization toolbox tools in recent releases do now have better interfaces that allow for essentially this kind of interaction.)
I mentioned preferences before. In fact, if you have my hpf toolbox installed on your computer, then try accessing the prefs for 'hpf'. On my computer, I see this:
DefaultNumberOfDigits: [50 5]
In the preferences, that tool puts several pieces of information. The tool itself can then extract them as needed. Preferences are a convenient place to store such information. But as a tool, hpf only has a few such overarching parameters that you may wish to set. And that makes preferecnes a decent place to store and access them, especially since prefs are remembered across MATLAB sessions.
Next, look at my SLM toolbox. It has a function called slmset.
EndConditions: 'estimate'
Extrapolation: 'constant'
FminconAlgorithm: 'interior-point'
LsqlinAlgorithm: 'interior-point'
slmset is a function that returns a structer with the default value for every possible property. You can also call slmset with property value pairs to create a similar structure with your choice of properties. Calling the slmengine code with no other arguments than some data, and you get all the defaults from slmset applied, thus:
prescription: [1×1 struct]
Extrapolation: 'constant'
As you see in the call to slmset, the default for 'knots' was 6. If you want to use some other value than the default, you override it by providing the specific property, as:
spl = slmengine(x,y,'knots',12)
So here 12 knots would be used, but all other properties reside at their default values.
Had I wanted to be even more user friendly, suppose you alwys find yourself changing my defaults for some property? Then I might have used preferences to allow that to work. (Note that this is NOT something that slmset checks, but I could have written it that way, to be even more user friendly.)
setpref('slm','knots',12)
I could now access that preference.
There are surely many other schemes that can be used. And some schemes will be better than others in various applications.
