How to deal with long argument list

[icwchan]

Hi everyone,

So I'm familiar with the popular advice that global variables should be avoided whenever possible, but I'm wondering how seriously people in scientific programming obey this rule of thumb.

I am current engaged in writing some code for semiconductor transport, and I'm finding that I require a lot of data that needs to accessed practically everywhere in the program (eg. for example, I have a set of wavefunctions that are used in a multitude of different calculations.) I tried avoiding the global route at first, but the argument lists for my subroutines were getting obscenely long (I stopped at around 15 for one of the functions). Finally exasperated with the constant parameter list fiddling and debugging, I gave up and bundled everything up into a (almost) universally accessible module (in case you were wondering, I'm doing the heavy number crunching in Fortran 90 with f2py for use in a python framework).

I'm sure I'm not the first person to encounter this problem, but most of my googling turns up results from CS guys who think global variable users should be drawn and quartered; I hope it's okay to ask for a second opinion here, hopefully from someone experienced in scientific programming... What's the usual approach to passing around large quantities of data internally in a program?

Thank you in advance!

IC

 

[G037H3]

I don't know if this will help or not..: http://stackoverflow.com/questions/423379/global-variables-in-python

 

[icwchan]

Thanks for the quick reply, but I have no troubles understanding *how* to use global variables. My issue is *when*, if ever, can I or should I use them. The website you linked only addresses the former.

More specifically, how does one handle situations in which large quantities of data need to be accessed all over a program? Is massive parameter lists really the way to go? Or do people just leaving it floating around and readily accessible, like in a MATLAB script?

 

[Mark44]

Instead of having an argument list with a whole raft of parameters, have one parameter of type STRUCTURE. It's been awhile since I've done any programming in Fortran, and I don't remember writing functions/subroutines with STRUCTURE parameters. That's how it's done in C and C++ and related languages when you want to pass a lot of information into a function and don't want to have to hassle with a bunch of parameters.

In general, it's considered better practice to pass parameters to a function rather than use global variables.

 

[rcgldr]

I don't see an issue with truly global variables if their usage by functions is documented. One advantage is that you can do a text search to find all references to a global variable in a set of source files. In the case of a passed parameter, the function's local name for the variable may be different, making it more difficult to locate all references to a specifc variable that is global in nature. I would recommend you keep all actual instances of global variable declarations in a single (or as few as possible) source module(s), rather than having them scattered throughout set of files, but it seems you've already done this.

If the issue is a long argument list as opposed to a variable that is truly global in nature, then as suggested, using a structure would be a good idea.

 

[story645]

If you're using python, args and kwargs clean up a lot of the really long function defs: Langauge Reference

And you can pass dictionaries into functions if you use the same keywords the function does, so if the function is maths(sum,total) and vars = {'total':12,'sum':8}, maths(vars) will work the same as maths(8,12)

My latest approach to this problem (something like 20 params as of now) is to bundle up my data as an object and to pass the object around to the various functions that need the parameters. I guess this is the python equivalent of using structs.

My old method (and I still use it for some testing purposes) is to build a dictionary of my parameters and then call a function to grab the dictionary whenever I need values, so:

def getparams():
    pars = {'par1':...
               ...
              'parn':...}
    return pars

and then whenever I need to pull something, it's just
pars = getparams()

 

[DrZoidberg]

If you are dealing with constants e.g. the number PI or the speed of light etc. then you don't pass that as an argument into a function. Such constants are always global or part of some object/class that can be accessed globally.
Global constants are perfectly fine. It's just global variables that should be avoided if possible. But of course there are also cases where global variables are the best option. E.g. in a game the data structure that represents the "world" is usually global.

 

[icwchan]

Someone correct me if I'm wrong, but the impression I'm taking away from this is that with some caveats, I do not need to avoid globals like the plague (eg. okay for "world" data, keep it all in one file etc). Which is good, since that is the answer I was hoping for. Or I can try to pass around a large custom structure (not sure if f2py handles that very well, however, but will check...)

Thank you to everyone for their response, I appreciate it.

 

[D H]

In many places, you absolutely do need to avoid globals like the plague. Globals rank right up there with "go to" in terms of "things to avoid at all costs" (aka "things that require a waiver from high-level management").

It sounds like you are not using any concepts from object oriented programming at all. If you are using anything that resembles a modern programming language you should at a bare minimum be using encapsulation techniques.

 

[rcgldr]

As DH mentioned, it depends on the group of people you work with or the authors of CS books and their standards (if there are any). Some groups treat programming more like a religion than a science, and it's in these groups where you find that globals and goto's are to be avoided. One of the things you typically do at a new programming job is to find out what the groups standards are, which usually involves naming and documentation conventions. There may be actual written standards, or you can simply ask others in the group and browse the existing code.

Getting back to the OP, Fortran 90 supports structures, so you could use those for parameters that can be logically grouped. I'm not sure if or how these structures can be passed between your Fortran and Python code.

 

[D H]

Some groups treat programming more like a religion than a science, and it's in these groups where you find that globals and goto's are to be avoided.

I would argue that it is the other way around: It is those places that do not treat programming as a science where you find excessive use of globals and gotos. One of the earliest results of treating programming as a science was finding what aspects of programming were highly correlated with buggy code. Right at the top of the list are global variables and gotos. Organizations ban their use precisely because they treated programming as a science.

 

[rcgldr]

... global variables and gotos. Organizations ban their use precisely because they treated programming as a science.

Getting a bit off topic, goto's were discussed in this ancient thread:

https://www.physicsforums.com/showthread.php?t=308782

Similar type exceptions exist for the usage of globals. In a multi-threaded or multi-tasking environment, you have some variables, like message queues, that are global in nature. Constants or the nearly equivalent of variables that are initialized only one time are also valid candidates to be globals.

 

[CyMark]

Sort of new here and haven't dealt with Fortran for 25 years, but this is what I do in all my designs.

I have a class or structure called DirectiveInstructions, which captures all the config. It is called first when the main thread starts. It can do three things:

1. Read command line arguments
2. Read a config file
3. Read DB table

So now I can put all things, that I may want to fiddle with without re-compiling the program, in one or more of the above places. This class also contains all fixed variables, default values and strings I would use throughout.

A reference to this class is passed everywhere so every thread, object or function that needs "Directives" has them at hand. Nicely separates the config from your code and you only have one pointer to pass.