MATLAB Answers

0

Coding Practice: Naming and best practices for 'overhead' variables

Asked by D. Plotnick on 22 May 2018
Latest activity Commented on by Walter Roberson
on 22 May 2018
Hello all, I have a couple of questions regarding what I will refer to as 'overhead' variables. Examples of these would be variables controlling/identifying: the version of Matlab, whether to use a GPU because a CUDA enabled one is available, the location of a diary/log file, the current evaluation time for different parts of the script, etc.
These variables do not store data, but may be used in different ways by subfunctions during the execution of a code, and need not be retained after code execution. So:
  • What is the proper name for these types of variables? Is there one? They are really controlling parameters for the execution of a set of functions, but thats a clunky name.
  • Is there a best practice for handing these to a bunch of sub-functions. I am currently using a structure, and a bunch of input parsers, but this requires a fair amount of rewriting any time I modify or add a new overhead variable. I know that global variables are a thing, but avoid them like the plague. Is there a better/cleaner way of handling these in Matlab?
Cheers, Dan

  0 Comments

Sign in to comment.

1 Answer

Answer by Walter Roberson
on 22 May 2018
 Accepted Answer

Back in the late 70's and early 80's, the state of the art for programming was Edward Yourden's books on Structured Design. One of the points they made was to clearly separate State from Data. The variables you are describing would mostly have been described as State variables.
Although distinguishing between State and Data can help clarify thinking, Computing Theory, in particular Turing Machines and the techniques of Lambda Calculus, show that other than the distinguished "current" instruction, in theory State and Data are indistinguishable.
For example, in
for K = 1 : 5
fprintf('%d', K*ones(1,K));
fprintf('\n');
end
K is both State (row number) and Data (content to print), and there can be no useful distinguishing between those.
All of which is to say... It doesn't matter. You do not need to distinguish these as being somehow "different".
Consider your example of a CUDA variant being available. There might be use for a variable that stores that fact, but that variable is probably not what should be passed to the lower level routines. The lower level routines should either be passed a function handle that does the work "somehow", or else should be passed a flag that indicates whether to use the CUDA variant. Because even though a CUDA variant might be available, that does not mean that it should always be used. The user might know that they have a slow GPU, or the user might want to compare the results of CUDA vs non-CUDA because the user is seeing significant round-off effects.

  4 Comments

Show 1 older comment
Where do iteration counts fall into your categories? The user may well want to know how many iterations have been done so far, or might need to know that the process failed on row #83279 of the data file, which is an iteration counter.
Interesting question, and can see that has the same issue as your looped K example above.
I would say that the above categories apply to variables I wish to use as inputs/outputs to subfunctions, but I will often use iteration index as an input value for cellfun and arrayfun type operations, where the iteration index doubles as e.g. row index. Thus, iteration index may be used for multiple task types, including state monitoring (waitbar) and error checking/logging. It does not fit neatly into a box.
I will console myself that iteration index is rarely (with the exception of arrayfun type operations) passed between functions and thus I have little reason to try to drop it into some input/output structure for later use. It will remain one of those unfortunate intra-function variables, like outputs of "sz = size(Matrix)", that clutter my workspace during debugging.
I pass loop indices between functions so that the lower level functions can report on progress in a user-friendly way. For example,
fprintf('Best from phase A of iteration #%d was %g\n', iter_count, best_cost);

Sign in to comment.