works for me.
On Fri, Jun 8, 2012 at 7:08 AM, Daniel Russel drussel@gmail.com wrote: > OK. Does 10 work for everyone? > > On Jun 8, 2012, at 12:40 AM, Yannick SPILL wrote: > > 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 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 > > > > > _______________________________________________ > 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 >