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. >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > >