just my 2 cents:
I const_cast things. Don't know if it's a good thing, people were telling me to avoid mutable.
I'm ok with dina that we need something more standardized.

Y


Le 07/06/12 00:19, Daniel Russel a écrit :
It might make sense to introduce something a DistancePairScore base. It could have an evaluate that takes the distance between the two particles and the difference vector (and maybe the distance to avoid dup sqrts). One could then have a variant of PairsRestraint that takes a list of such pair scores and caches things for each pair passed in.

It would also have the nice advantage of making it clear that certain scores are invariant to rigid transforms and so provide a more principled basis for ignoring, eg, terms that are within a rigid body or not recomputing things when rigid mc moves are performed.

Doing this would involve forking:
IMP::PairScore (and corresponding macros)
IMP::core::PairRestraint
IMP::container::PairsRestraint
IMP::internal::TupleRestraint
IMP::internal::ContainerRestraint

On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman <duhovka@gmail.com> wrote:
I think we need more general caching mechanism. For example, if my
score includes LennardJones and Coulombic terms, currently each one
will compute the same distance, in addition there is external
calculation that decides if we should score the pair of particles
based on the distance between them. so instead of one distance
calculation there are three. It would be great just to be able to pass
the distance to evaluate() to avoid additional calculations.

On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel <drussel@gmail.com> wrote:
> You can mark member variables "mutable" to mean they aren't const when the
> class is. This is generally used for caches and stuff like that. In general,
> declaring a method const is used to imply logical constness instead of
> physical constness. That is, it means that doing it 2x with the same
> arguments should give the same answer, rather than that none of the bits
> should change.
>
>
> On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh <barak.raveh@gmail.com> wrote:
>>
>> Hi,
>>
>> Let me consult with the high IMP society about some IMP scoring and
>> caching design issues, don't wanna mess things up.
>>
>> I've been profiling code, and consequently wanted to cache some
>> intermediate computations that are made during pair score evaluations (e.g.,
>> the distance between particles). I just need the last intermediate from each
>> computation, so I thought of simply adding a [cache_] variable to my scoring
>> class, and store the intermediate computations there. BUT, ::evaluate() and
>> ::evaluate_index() are const functions, so I can't do that. Another option
>> is to add an output parameter to ::evaluate(), but that's also not very
>> clean. Is it absolutely necessary that these functions are const? Or any
>> other suggestions so that I can cache intermediate calculations during
>> ::evaluate()? This can speed some things up considerably.
>>
>> Barak
>
>
>
> _______________________________________________
> 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



_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev