great. any volunteers who are familiar with the imp kernel?
frido
Daniel Russel wrote: > 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 >>> >>> >>> >> >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >