mailRe: relax-users Digest, Vol 16, Issue 9


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

Header


Content

Posted by Gary Thompson on September 18, 2007 - 16:38:
relax-users-request@xxxxxxx wrote:
Hi,

I've reviewed the patch attached to bug #10022
(https://gna.org/bugs/?10022), and have found an issue.  The problem
is with the use of two dictionaries for the previous and current run.
The issue is that order in a dictionary is not guaranteed, and hence
the comparison may not work.

Hi I have two thoughts here ( I haven't seen thr patches so I can't be certain that I am on ther

1. if you compare two dictionaries with the same contents though the absolute order of the contents are not guarunteed within the same python interpreter they will have the same order and the dictionaries can be compared e.g.

test = {'1':1,'2':2,'3':3}
test2={'1':1,'2':2,'3':3}
test==test2
True
test3={'1':1,'2':2,'3':4}
test3==test2
test4={'1':1,'2':2,'4':3}
test2==test4
False

whats more the way python is structured they would have forbidden dictionary comparisons if they weren't possible

if you need to extract all they keys and compare the contents in order then the thing to do is call keys on the two dictionaries and put the results in a set and then lookup by the keys from the set while properly guarding for missing keys


reading more on this the dictionaries you are looking at seem to be keyed by residue (or is it an arbitary something else i.e. just and index in which case ed comment is fair)

        for i in xrange(len(self.relax.data.res['previous'])):
            if hasattr(self.relax.data.res['previous'][i], 'model'):
and

        for i in xrange(len(self.relax.data.res[run])):
            if hasattr(self.relax.data.res[run][i], 'model'):


which you are looking up by an xrange call so the order of i by which you are comparing seems to be well defined...


now from the look of the problem:

       residue 1: prev=None curr=m2
       residue 2: prev=None curr=m2
       residue 3: prev=None curr=m2
       residue 6: prev=m2 curr=m4
       residue 7: prev=m2 curr=m1
       residue 9: prev=m4 curr=m2
       residue 11: prev=None curr=m2
       residue 12: prev=m2 curr=m3
       residue 13: prev=m2 curr=m3
       residue 15: prev=m2 curr=m1
       residue 16: prev=m3 curr=m2
       residue 17: prev=m3 curr=m1
       residue 18: prev=None curr=m3

surely we need to do the following to compare results excluding those which 
have none from the previous round

         lookup_keys = []
        prev_models = ''
        for i in xrange(len(self.relax.data.res['previous'])):
            if hasattr(self.relax.data.res['previous'][i], 'model'):
               if not self.relax.data.res['previous'][i].model == None:
                   prev_models = prev_models + 
self.relax.data.res['previous'][i].model
                   lookup_keys.append(i)

        # Create a string representation of the model-free models of the 
current run.
        curr_models = ''
        for i in lookup_keys:
            if hasattr(self.relax.data.res[run][i], 'model'):
               if not self.relax.data.res[run][i].model == None:
                   curr_models = curr_models + 
self.relax.data.res[run][i].model

        # The test.
        if prev_models == curr_models:



now I maybe missing a trick here because I came late to the party but If not I hope it helps


regards
gary
 Maybe a simple test such as "if
self.relax.data.res[run][i].model == None" or its negative after
testing for the presence of the 'model' attribute, and removal of the
dictionary would remove the problem.  Significant simplifications to
the code after the comment "# The test." could also be made.

As for the code in the section "NOTE:  the following code has not been
extenstively tested", this does not directly address the bug itself
and it will have problems with the dictionary ordering.  I would
prefer that this section not be present in the patch.  If someone does
have different residues in two different iterations of
full_analysis.py then this error is much more severe and belongs
elsewhere other than in the convergence tests.

Cheers,

Edward






--
-------------------------------------------------------------------
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
-------------------------------------------------------------------





Related Messages


Powered by MHonArc, Updated Wed Sep 19 17:20:47 2007