Daniel Russel wrote:
The previous example with derivatives and a bit more detail.
Looks good to me overall.
Note that I haven't really looked at Ben's vector3 and haven't tied it to XYZDecorator (maybe Ben has), but it I expect all the needed operations will be there eventually.
Sure, it's just a simple triple of coordinates, so it's not hard to add new methods. XYZDecorator currently has a single method get_vector_to() which returns a vector between two particles.
Assuming others don't suddenly pop up with problems, this seems like a solid route to me. I propose:
1. We settle on names for the two base classes. I suggest SingleVariableFunction and ParticlePairScorer. Unless I'm still not understanding your proposal correctly, most non-bonded and/or dynamic restraints will use a ParticlePairScorer underneath (which may in turn use a SingleVariableFunction) while some static restraints may use a SingleVariableFunction directly.
2. I will do the rename of ScoreFunc to SingleVariableFunction immediately after (1) is decided.
3. Let's leave the evil Restrainer restraints alone for now, at least until I get a chance to write some proper tests for them (you may recall that one of the tests passed just fine without any particles in the system). This means leaving BasicScoreFuncParams for the time being (don't worry - it'll die - just read on).
4. Whoever ends up needing a ParticlePairScorer first can write the code. ;) New restraints can use the new framework.
5. Once we have a nice collection of scorers, somebody (probably me, unless others are desperate for this thankless task) can fix the Restrainer restraints and get rid of BasicScoreFuncParams.
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle