On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill <
yannick@salilab.org>
wrote:
> 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
>
>
>
> _______________________________________________
> 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