if it were a little earlier (like 10-10:30) I could skype in
Y
On 06/07/2012 09:22 PM, Daniel Russel wrote: > Sounds like a good idea. How about next Wednesday at 11 (PST)? Can > everyone who is interested make it or VC in then? > > On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman <duhovka@gmail.com > mailto:duhovka@gmail.com> wrote: > > maybe we should have an IMP "high society" meeting and think how to > improve both software design and performance of scoring functions. I > have been looking into atomic resolution functions recently and have > some suggestions there, and Daniel and Barak know what we need for low > resolution. So we can come up with something that will cover all > resolutions efficiently. > > On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill <yannick@salilab.org > mailto: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 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 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 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