Anyway, it seems like the DerivativeAccumulator is worth having. For now
we can punt on weights and say that the first person who wants them
writes a WeightedRestraintSet class which stores a weight and a set of
restraints and manipulates its restraints.
Friedrich Foerster wrote:
just my two cents to the conversation:
- i would greatly appreciate if the usage is as simple and intuitive as
possible. the end users will ideally be biologists if imp should really
have significant impact. for that purpose i would rather not prefer to
see all kinds of pointers floating around on the python level.
from that point of view i vastly preferred option 1 of ben's original
proposals.
- from a philosophical standpoint weights just influence the output. but
realistically a user will want to influence also the restraint during
the optimization.
an example: volume exclusions are often modelled as r^-12 potential (eg
in modeller, i think). if i intend to use such an expression, it will be
much more sensible to change the radius during optimization - and that's
what our great hero frank actually did. so it would make sense to access
them the same way, i argue.
- by the way, it might be useful to include some more tags to the
restraints to account for hierarchies. either some fixed number of
hierarchies (frank had 14, i think) or fancier to model the universe.
frido
Daniel Russel wrote:
or model.set_weight(myrestraint_index, .5) or
model.set_weight(my_restraint_pointer, .5);
or restraintset.set_weight(r, .5);
I don't like the second because it requires the model to keep a second
bunch of restraint pointers hanging around, and then you have to keep
them synchronized with the 'real' list of restraints (what happens if
you remove a restraint from a model, or you delete a restraint and
then
create a new one which happens to have the same address?) I _really_
don't like the first one because 1) it requires the list of restraints
to remain ordered and 2) it wouldn't work with restraints that live
inside other restraints.
They just require that either the model/RestraintSet (for the first)
store the Restraint pointers in a vector of std::pairs with weights
and return the index (just like the Particles) or, for the second,
just in a map or any other container and go and find the correct
restraint when the weight is set. Simple enough. No duplications and
no significant overhead.
And the user has to keep around the identity of the restraints he is
interested in somehow anyway.
If you like the third, why not compromise and say just that any
RestraintSet can scale its children.
The third is the same as the first, just that both models and
restraint sets store lists of restraints.
Yes, I figured you'd say that. ;) On the other hand, adding a scale
member to the Restraint base class adds a per-object overhead, and
maybe
it's better to only have that for RestraintSets. So we can agree
not to
put it in Restraint, but for different reasons...
Well, one word is pretty negligible. Especially with that mysterious
list of particles there already :-)
Sure. But that requires copying the object and keeping them
synchronized. Not that I see any particular application of this :-)
Maybe I'm missing something here, but a RestraintSet (currently) just
keeps a vector of pointers to Restraints. So there's no reason why the
same Restraint object couldn't be in two sets.
Yes, but if we store the weight in the Restraint, it can't really be
in two sets any more because the weights are linked.