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 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 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 >