It was pointed out that the thing we call a "residue index" in imp appears to be more commonly referred to as a "residue number" (that is, the number of the residue as stored in the pdb file). Given that there are a number of classes involved and it may involve a lot of outside code, it is unclear how to best deal with it.
The things affected include - IMP::atom::Residue::get_index() and set_index() - IMP::atom::get_residue_index() - IMP::atom::Selection (the residue_indexes and residue_index arguments and functions) - IMP::atom::Fragment, various functions - IMP::atom::Domain, various functions
Possible actions are: 1) improve the documentation to say residue index= residue number as we tend to use the name index for such things in IMP 2) provide new functions which use number instead of index in their names and hide the old ones from the docs (but support them indefinitely, as they are all very simple) 3) provide new functions and deprecated the old ones 4) remove all such functions :-)
Thoughts?
On 5/3/11 3:23 PM, Daniel Russel wrote: > It was pointed out that the thing we call a "residue index" in imp > appears to be more commonly referred to as a "residue number" (that > is, the number of the residue as stored in the pdb file).
Whoever pointed that out was incorrect. ;) The two are subtly different:
- Residue index is sequential; you are (pretty much) guaranteed that residue(our index+1) is the next residue and residue(0) is the first residue in a chain. - PDB residue number is not sequential, and in fact may not even be a number. ;) Since the residue number is derived from the sequencing, you may have gaps in the numbering (if structures are not available) which I guess is no big deal, or you may have extra residues with insertion codes (e.g. PDB residue numbers may go 4, 5, 6, 6A, 6B, 7, 15, 16).
Before forcing the two to be the same you'll have to figure out what to do with insertion codes.
Ben
On May 3, 2011, at 4:45 PM, Ben Webb wrote:
> On 5/3/11 3:23 PM, Daniel Russel wrote: >> It was pointed out that the thing we call a "residue index" in imp >> appears to be more commonly referred to as a "residue number" (that >> is, the number of the residue as stored in the pdb file). > > Whoever pointed that out was incorrect. ;) Actually, based on what you say below, they were quite correct :-)
> The two are subtly different: > > 1 Residue index is sequential; you are (pretty much) guaranteed that > residue(our index+1) is the next residue and residue(0) is the first > residue in a chain. We don't have any explicit storage of this in IMP other than a Residue being the ith child of a Chain. I'm not sure there is any need for storing/dealing with such a thing as one can simply traverse the tree.
> 2 PDB residue number is not sequential, and in fact may not even be a > number. ;) Since the residue number is derived from the sequencing, > you may have gaps in the numbering (if structures are not available) > which I guess is no big deal, or you may have extra residues with > insertion codes (e.g. PDB residue numbers may go 4, 5, 6, 6A, 6B, 7, > 15, 16). Currently this "PDB residue number" is what is called "residue index" in IMP. The insertion code is stored separately and not many operations support it as no one has cared. One can always add insertion code support to Selections and such when there is demand.
On 5/3/11 5:02 PM, Daniel Russel wrote: >> 1 Residue index is sequential; you are (pretty much) guaranteed >> that residue(our index+1) is the next residue and residue(0) is the >> first residue in a chain. > We don't have any explicit storage of this in IMP other than a > Residue being the ith child of a Chain.
Ah yes, you're absolutely right, of course. It was the child indices I was thinking of.
> Currently this "PDB residue number" is what is called "residue index" > in IMP. The insertion code is stored separately and not many > operations support it as no one has cared. One can always add > insertion code support to Selections and such when there is demand.
Makes sense. In that case it should be made clear to the user that the residue number/index is not unique, since it is a common mistake to assume it is. (I guess we should mention that we don't enforce that the (residue number, insertion code) tuple is unique within a chain.)
Ben
participants (2)
-
Ben Webb -
Daniel Russel