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 <" target="_blank">>
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 <">>
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 <">>
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
>
>
>