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
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle