Edward d'Auvergne wrote:
You have found some more ancient relax legacies. There is a lot of
perfectly functional legacy code in there!
I suspected so ;-)
These counters should
probably not be placed into 'self'. They are re-initialised to zero
at the start of each iteration of the main model-free minimise() loop.
The only place these are now accessed from is the minimise()
function. The placement into 'self' is not always for storing state,
it has been used so that other functions can access the data without
having to pass arguments between the instance methods (which
technically is state anyway :).
I would definitley call that an anti pattern It confuses the design of
the program in nasty ways (I spent ages trying to work out what all the
apparent state of model_free was when there was virtually none).
Another way to look at this is why do we have functions: they are
interfaces between one piece of code and another and are designed to
make code flow clearer. Storing non-state in an objects fields or a s a
way to pass state from one function to another is somewhat equivalent to
how some people use common block in fortran in some situations and we
all know how tractable that is ;-)
anyway rant off
Yet in this situation this is no
longer the case.
The model_free instance is not singleton. There is a single instance
located at 'self.relax.specific.model_free' which all of relax
accesses. But the class can be reinitialised as many times as you
like, although there probably isn't much use for this (then again I
can't foresee what others will do with the module).
Thats fine I can cope with this (as you see from the latest code I save
a reference to model_free on each call in a memo) All I needed to do
was realize that these variables were reinitialise each time through
the model_free minimise instance creation loop. I was just worried
about unexpected side effects I hadn't spotted.
regards
gary
Cheers,
Edward
On 3/29/07, gary thompson <garyt.and.sarahb@xxxxxxxxx> wrote:
Another question about parallelising model_free minimise
model_free.py carrys around a grab bag of state and some of what might
be called pseudo state for the object (some of the state is only
relevant within one function call and effectively is a hidden local
variable and method/function argument e.g param_vector and
self.disassemble_param_vector). Now specific_fns.model_free.minimise
has the following code after the minimise and self.f_count etc are
clearly state
self.f_count = self.f_count + fc
self.g_count = self.g_count + gc
self.h_count = self.h_count + hc
who and what is this state save for and where is it accessed? because
i might well not have the same minimise instance when I get back from
multiprocessing to save it to (or is there only one instance of
model_free? is it a singleton? it certainly looks so from my tests
and in actual fact effectively this data is module level data in
specific_functions.model_free am I correct ;-)
.
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: how to parallelise model_free minimise