Daniel Russel wrote: > For example, if you > want to add a child to a node, it saves a few lines not not have to > check if the child count is there already or not.
Granted, it would be useful there.
> I think the wiki page with the attributes says it all--it is just a > general tree. You have parent and child "pointers", a counter for how > many children and a parent index and a string naming what sort of thing > you are. I am pretty sure we shouldn't have anything less general > (unless we want to fix that a residue always has a chain as a parent) > and unless you want to support DAGs, I am not sure what a more general > thing to support is.
Well, I was thinking from the other direction - a container class which can contain particles and/or other containers. So for example, a rigid body would be a simple container of particles, a residue would be similar, while a chain would be a container of residues. (Whether you have an actual Residue class derived from Container, and whether it's done at the C++ or Python level, is debatable.) The two approaches are, of course, essentially equivalent.
If the wiki page is going to be the only information I can work on, here are my concerns with it thus far: ;) - It seems odd to me to treat a bond as a 'particle'. Would you do angles and dihedrals in the same way? - Is Residue just an example of a member of a hierarchy, or would chains and proteins be treated differently? - How would you deal with references to particle IDs to turned-off particles? "PI" is just an Int variable, right? - If I wanted to pull out every atom in residue 1, I'd really have to scan through every single particle to figure out which ones a) have a residue attribute and b) have it = 1 ? That seems inefficient.
Ben