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 > mailto: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 > mailto: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 mailto: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 mailto:IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org mailto: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