[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] score function weights



BTW: the more observant may have noticed that this is now a "proper" mailing list. So please address further emails to , and direct interested people in the lab to the IMP wiki page (which links to the mailing list archive and the sign-up page). imp@salilab will redirect to imp-dev for a while, but you'll get a 'message has implicit destination' error which I have to override. So use imp-dev. (It's imp-dev rather than imp because at some point there will be an imp-users as well, and perhaps an imp-commits if people want it, for notification of SVN commits.)

Daniel Russel wrote:
Ben Webb wrote:
It seems like option (2) would be able to handle this more easily - either that or we use option (1) together with something like the DerivativeAccumulator that Keren proposed. Why don't you like option 2?
Option 2 basically is the DerivativeAccumulator. On reflection, I do like it. - The restraint has a single evaluate function which takes a pointer to a DerivativeAccumulator (which is NULL if no derivs are to be accumulated). No more bool. Can we do this with swig? I would assume NULL gets translated into null. This has the added advantage that you can't set derivs if you are not supposed to.

Yes, that should be fine. Python 'None' should go through as a C++ null pointer. If it doesn't, then it would be easy to write a typemap for.

- To evaluate a restraint (either in the Model or as an outer nested restraint) you get the weight, w, and tell the DA to multiply its weight by w (push it on to a stack of weights). Then you call evaluate, multiply the return value by w and tell the DA to pop the last weight. - the weights are stored separately from the restraints since they are no longer handled by the restraint

I don't like stacks like this, for many reasons (threading and exception safety spring to mind). And I'm not sure where you'd store the weight, if not in the restraint. Why not just in the Restraint base class?

My alternative to stacks: restraints which contain other restraints would use a copy-like constructor to make a cloned DerivativeAccumulator, multiplied by their own weight, and then pass that to their child restraints' evaluate methods.

	Ben
--
                      http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
	- Sir Arthur Conan Doyle