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 >