mailFuture direction of the data structure 'self.relax.data'.


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on May 24, 2006 - 05:39:
This is a continuation of my response to the thread started by Chris
at https://mail.gna.org/public/relax-devel/2006-05/msg00006.html.  I
thought I would start a new thread as this is a bit of an aside.

Eventually one of the goals of relax is to change the structure of the
data structure 'self.relax.data'.  Having each object inside
'self.relax.data' as a dictionary where 'self.run' is used as a key to
select the run specific data is clumsy.  A much cleaner implementation
(which would be completely invisible to users) would be to have
'self.relax.data' as the dictionary in which 'self.run' is used to
select between the run specific data.  Then there would only be a
single point within the entire program where run specific data is
selected.  You could then type something like:

   data = self.relax.data[self.run]

and then never reference the run again in that block of code.  Each
run would then have it's own area within 'self.relax.data' completely
to itself.  This could simplify things when new types of data analysis
(SRLS, relaxation dispersion, etc) are added to the program.

Another part of this change would be to remove the run option from
most of the user functions.  This would be very visible to users.  The
idea would be that you use a special user function to select which run
you would like to be in and then all subsequent user function calls
assume the 'current' run.  The execution of relax would then involve
jumping between different runs.

For most user functions this will be very easy to implement.  However
for those functions which transfer data between runs, for example all
the copy() functions and the model selection function, the approach
will be a little more complex.  Much of the inefficient passing of the
run strings inside relax would then be dropped.  The entire code base
would be simplified -- though the changes involved would be huge and
cause many breakages.

Bye,

Edward



Related Messages


Powered by MHonArc, Updated Thu May 25 04:21:17 2006