OK, I have hopefully fixed this problem now. It was a bug in a couple of
(technical) ways. It should be faster and use less memory now, as well
(not that you will notice that, because this operation is down in the
noise). I have tested it a bit and it seems ok but if you notice anything
odd let me know, because this was a fairly major re-write of that specific
functionality.
Wayne
On Wed, 29 May 2013, Wayne Boucher wrote:
> Hello,
>
> Fortunately Tim passed through the department just now so I had a free
> consultation on this. And that quickShiftDict implementation is definitely
> causing the problem. But it turns out the way it is being used also needs
> fixing, so it's going to take a bit of time to do and test.
>
> Wayne
>
> On Wed, 29 May 2013, Brian Smith wrote:
>
>> Hi,
>>
>> We're using fully updated v2.2 and recently noticed that crosspeaks close
>> to 10 ppm don't get all their assignment possibilities listed in the
>> assignment popup, nor when you make shift matched restraints. Peaks just
>> below 10 ppm pick up potential assignments up to 9.somthing ppm while peaks
>> 10 ppm and above pick up only assignments above 10.0 ppm. For a peak above
>> 10 ppm, setting the assignment tolerances wider eventually starts picking
>> up (presumably aliased) shifts at the other end of the scale.
>>
>> We can't track down any reason within the project as to why this should
>> have arisen, but I'm suspicious of the quickShifts functionality in
>> ccpnmr.analysis.core.AssignmentBasic. It seems to me that the different
>> rounding of the shifts either side of position=10 to generate the keys for
>> the quickShiftDict will mean that shifts just above 10 will have key=10
>> while those below will have key=99 (and those between 1 and 1.1 will also
>> have key=10?). If I understand the code right, the subsequent
>> quickShiftDict.get(key) then won't pull out the 99s if called with a 10 and
>> vice versa?
>>
>> I'm guessing that you chose 10 as a cutoff for different treatment in order
>> to get reasonable "density" of keys in 1H (mostly below 10 ppm) and
>> heteronuclei (mostly above 10 ppm). Would it not be less risky to use just
>> the first two significant figures as a key with a format and reconversion
>> to float? This is probably rubbish, but maybe...
>>
>>
>> float('%.2g' % position)
>>
>> There are a bunch of suggestions at
>>
>> http://stackoverflow.com/questions/3410976/how-to-round-a-number-to-significant-figures-in-python
>>
>>
>>
>> Dr. Brian O. Smith --------------------------- Brian Smith at glasgow ac uk
>> Institute of Molecular, Cell and Systems Biology & School of Life Sciences,
>> College of Medical, Veterinary & Life Sciences,
>> Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
>> Tel: 0141 330 5167/6459/3089 Fax: 0141 330 4600
>> ----------------------------------------------------------------------
>> The University of Glasgow, charity number SC004401
>>
>
|