From wbrisken@nrao.edu Fri May 25 14:05:44 2007 Date: Fri, 25 May 2007 14:05:05 -0600 (MDT) From: Walter Brisken To: aips2-naug@aoc.nrao.edu Subject: [Aips2-naug] Institutional memory proposals To prime the discussion on parameter memory scheduled for NAUG on May 30, David and I have each come up with a concrete scheme for managing remembered parameters. I will be away next week so I'll let David lead discussions on both of these as appropriate. PART I -- Walters Restricted Solution We have devised two proposals, which can be called the "restricted" and "general" solutions. Remember that parameters are remembered in two places: (1) .last files written by each task which are persistent across sessions, and (2) python variables which are volatile storage. First, the "restricted" solution from Walter. Here is how it works: 0. At startup (of script or interactive session) all params are defaulted (.last files are not read). 1. At any time a single task is "current" or "in scope". Default is None. 2. TASK will change the current task without restoring from .last files. 3. INP will restore any saved parameters on task change from .last files to python variables but repeated calls to INP will not. 4. GO will remember all parameters to .last files. Unset parameters will not cause python variables to be set. 5. DEFAULT will cause python variables for the current task to be unset. 6. function() calls will use python variables that are currently set except those that are overridden by explicit parameters inside (). Explicit function parameters will not be remembered as python variables. function() calls will not write .last files. *** 7. If a .last file is to be read but does not exist, no change will occur. *** The last feature of 6 above could be changed based on majority opinion. This forces the user to see the variables whenever they may have changed due to restoration from .last files. In scripts since INP is not likely to be called there will be no confusion about resurrection of values from .last files and at the same time scripts can take advantage of the python variable memory for parameters that should stay the same. In scripts one could still use GO instead of the final function() call if all params are set to python variables as desired. This will have the effect of changing the .last files. Some examples: Assume F(a=0, b=1, c=2) and G(a=0,d=5,e=3) are tasks with defaults as noted ........... a = 4 F(b = 3) # runs F(4, 3, 2) # now a = 4, no other param is set. TASK G # G is now the current task. GO # runs G(4, 5, 3) ; saves .last file (a=4, d=5, e=3) # still a = 4 is the only python variable set b = 6 c = 7 F(a=12) # runs F(12, 6, 7) # a = 4, b = 6, c = 7 are now set # G is still the current task F() # runs F(4, 6, 7) G() # runs G(4, 5, 3) -- d and e are not python variables INP F # no .last file for F yet. no changes. current values shown: # a = 4 b = 6 c = 7 c = 0 a = 0 GO # runs F(0, 6, 0) ; saves last file (a=0, b=6, c=0) DEFAULT # unsets a, b, c F() # runs F(0, 1, 2) INP F # doesn't restore -- F is still current task. INP G # sets current task to G, sets python variables a=4, d=5, e=3 TASK F # changes current task, does not load .last INP F # show inputs, no change to python vars ........... Comparing this to aips: TASK does the same thing in both INP in casa is like TGET ; INP in aips if is not the name of the current task. It is equivalent to just INP otherwise. GO is identical Possible extensions: One could add to the above SAVE and RESTORE to force write/read of the .last files. (Think TPUT and TGET here) If INP changes the default task it could effectively do a SAVE before INP -- not sure if this is desired behavior though I think this is mostly compatible with Doug's comments and David's and Michael's wishes. Also it is not that different from what happens now. PART II -- David's General Solution Next is the "general" solution (from David). I think this provides the most possible flexibility to both interactive and non-interactive use. Here, I am only concerned with where the Python variables are used and altered; saving and restoring parameters from the .last file can work as before. Briefly, the system works as follows: 1. function() calls will NOT use python variables that are currently set except those that are overridden by explicit parameters inside (). Explicit function parameters will not be remembered as python variables. function() calls will not write .last files. 2. The functionality of go() will be expanded to include additional parameters which are NOT stored to python variables or the .last file. Let's use setjy as an example, with parameters "vis" and "fieldid". The defaults are: vis='' fieldid=-1 CASA<1>: setjy vis='a.ms' fieldid=0 # Runs with specified parameters, but does not save parameters CASA<2>: task 'setjy' CASA<3>: inp vis = '' # Name of input visibility file fieldid = -1 # Field index identifier CASA<4>: go setjy vis='a.ms' fieldid=1 # Again, runs as specified but does not save parameters CASA<5>: vis='a.ms' CASA<6>: inp setjy vis = 'a.ms' # Name of input visibility file fieldid = -1 # Field index identifier CASA<7>: go # Runs setjy as specified CASA<8>: go fieldid=2 # Run with fieldid=2 but do not store fieldid CASA<9>: inp vis = 'a.ms' # Name of input visibility file fieldid = -1 # Field index identifier CASA<10>: fieldid=2 CASA<11> setjy vis='b.ms' # Runs setjy with vis='b.ms' and fieldid=-1, does not save parameters # Note how the change to fieldid in command 10 did not affect this. Implementing this will require the use of an IPython input filter on the "go" command. -- Walter and David _______________________________________________ Aips2-naug mailing list Aips2-naug@listmgr.cv.nrao.edu http://listmgr.cv.nrao.edu/mailman/listinfo/aips2-naug