ok, I'll stop using digest mode :) Wed@10 (or any hour was suggested) works for me.

On Jun 8, 2012, at 12:58 AM, imp-dev-request@salilab.org wrote:

> Send IMP-dev mailing list submissions to > imp-dev@salilab.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://salilab.org/mailman/listinfo/imp-dev > or, via email, send a message with subject or body 'help' to > imp-dev-request@salilab.org > > You can reach the person managing the list at > imp-dev-owner@salilab.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IMP-dev digest..." > > > Today's Topics: > > 1. Re: caching advice (Dina Schneidman) > 2. Re: caching advice (Daniel Russel) > 3. Re: caching advice (Yannick SPILL) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 7 Jun 2012 11:06:42 -0700 > From: Dina Schneidman duhovka@gmail.com > To: List for IMP development imp-dev@salilab.org > Subject: Re: [IMP-dev] caching advice > Message-ID: > CAN4WCj=rCxgPss5GGM_kKZs40kBtxFOCvM26KWA9BLbDHyUnvQ@mail.gmail.com > Content-Type: text/plain; charset=ISO-8859-1 > > 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 >> > > > > ------------------------------ > > Message: 2 > Date: Thu, 7 Jun 2012 12:22:24 -0700 > From: Daniel Russel drussel@gmail.com > To: List for IMP development imp-dev@salilab.org > Subject: Re: [IMP-dev] caching advice > Message-ID: > CADEvLN7wesVz72HK3c9-DQh6DTjcpy8y2hNOZi8kHFZdEyBGbA@mail.gmail.com > Content-Type: text/plain; charset="utf-8" > > 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 >> >