sorry for my ignorance of this discussion for a while.
i presume most people will want to use imp in a probabilistic
framework rather than doing simulations with physical form-fields.
i.e. most people's scoring function will be a log(probability) rather
an actual energy. for consistency it would be nice to call the scoring
function with the according spatial observables, which are typically
distances and the corresponding error.
philosophically, i agree with with daniel that the name 'Harmonic'
requires a spring constant.
to make everybody happy, i would propose a new name for functions that
call the harmonic functions, but have spatial parameters as an input.
for example LogGauss, LogUpperDistanceGauss or whatever you agree with.
is anybody be willing to contribute something like that to the kernel
(i am an official application guy, so the kernel is 'tabu' for me)? i
think the current workaround, i.e. introducing scaling parameters
through the back-door, is a bit unsatisfactory and will confuse most
users.
thanks
frido
On Mar 15, 2008, at 5:31 PM, Daniel Russel wrote:
SWIG wraps pairs so that you can use first and second and [0] and [1].
Unfortunately, the
(a, b) = IMP.ParticlePair(pa, pb)
doesn't work, so it doesn't seem to be quite as nice as a true python
array.
Still, I think returning a pair is nicer than having different
signatures.
On Mar 15, 2008, at 5:06 PM, Ben Webb wrote:
Daniel Russel wrote:
I can do this very easily without any changes to the C++ code. But
maybe
for consistency between C++ and Python it makes more sense to
replace
operator() with evaluate(feat) and evaluate_deriv(feat, &deriv) ?
I like having C++ and python the same and (*f_)(value) looks kind of
silly anyway.
Agreed - so I put it in as r473.
If it can be made to work easily in python, I would propose have the
deriv version return a pair or tuple in C++ too.
Yes, I had that in mind when I proposed it - now that the methods
have
different names, we can have different return types. But I don't
know if
SWIG has any typemaps for pair or tuple - if not it might be a bit
awkward to make it work nicely in Python. It works just fine as is.
It would be really nice to be able to run tests on unary
functions.
Well, we already can, of course - just not on the derivatives.
Sure. But consistency between function and its derivative seems like
the main nontrivial thing to check.