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. >> >> Agreed. >> >> Ben >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> 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