MATLAB Answers

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

조회 수: 5(최근 30일)
D. Plotnick
D. Plotnick 2018년 5월 22일
댓글: Walter Roberson 2018년 5월 22일
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

채택된 답변

Walter Roberson
Walter Roberson 2018년 5월 22일
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
Walter Roberson
Walter Roberson 2018년 5월 22일
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);

댓글을 달려면 로그인하십시오.

추가 답변(0개)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by