- 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
You have to keep the objects around either way. In Ben's case because
you need the object to set the weight on it. In my case because you need
the object to identify it with the model for setting the weight. It just
is a matter of who you call the function on. The main simplification
that Ben's method brings is that you don't need to worry about who
contains a given Restraint. This might be enough to tip the scales.
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.
OK, but then they should be used in the same way--it is the restraints
responsibility to have a weight field or not and handle it properly and
the framework can't really touch it. The nice thing about treating
weight differently from things like radius is then weight can be handled
in a very standard manner and people who write restraints don't have to
worry about handling it properly.