IMP-dev June 2012

imp-dev@salilab.org

8 participants
13 discussions

Git and IMP and more frequent releases
by Daniel Russel 14 Jun '12

14 Jun '12

At the imp-dev meeting yesterday, the question of switching to git from svn was raised. The hope is that it would facilitate having more frequent mini-releases of IMP (monthly being a target) as it makes it much easier to maintain parallel development threads. The main advantage of git over svn is that it makes it very easy to make and maintain branches since one can merge branches repeatedly without problems. As an illustration, someone who is making a major change to a module that would take a while to implement could create a new branch in the repository for the change, lets call it distance_functions. While distance_functions is being developed, any changes made to the IMP main branch can be easy pulled into the distance_functions branch simply by doing "git rebase" (doing this is very painful with svn) allowing the two to keep in better sync. And when the change is done, it can be brought back into the main development trunk without complication (and done more than once if so desired). This change would also makes dealing with releases much simpler as a release simply means pulling changes from the main development trunk into a release branch and adding a tag. Any fixes we want to make to release can be easily done in a hotfix branch and then directly brought into both the release and the main development trunk, rather than having to be manually pulled into both places as with svn. At the meeting, a reasonably fraction of the people were already using git for other projects (and I'm using it instead of svn for accessing IMP). So learning it does not seem to be an insurmountable hurdlw I would also suggest we check out git flow. It defines a standard branch structure that supports releases, hotfixes to releases, feature development branches etc and provides scripts to aid in doing basic tasks. It is available on home brew, but there does not seem to be a standard rpm for fedora. Boost appears to be moving towards using it, among other projects. We can provide some kind of support for existing svn users (probably read-only). This may simply involve using git-svn to sync to the git head and push it to the existing svn repository.

2 3

Re: [IMP-dev] caching advice
by Daniel Russel 12 Jun '12

12 Jun '12

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(a)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

3 9

Re: [IMP-dev] IMP-dev Digest, Vol 55, Issue 2
by Barak Raveh 08 Jun '12

08 Jun '12

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(a)salilab.org wrote: > Send IMP-dev mailing list submissions to > imp-dev(a)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(a)salilab.org > > You can reach the person managing the list at > imp-dev-owner(a)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(a)gmail.com> > To: List for IMP development <imp-dev(a)salilab.org> > Subject: Re: [IMP-dev] caching advice > Message-ID: > <CAN4WCj=rCxgPss5GGM_kKZs40kBtxFOCvM26KWA9BLbDHyUnvQ(a)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(a)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(a)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(a)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(a)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(a)salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev(a)salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > > > ------------------------------ > > Message: 2 > Date: Thu, 7 Jun 2012 12:22:24 -0700 > From: Daniel Russel <drussel(a)gmail.com> > To: List for IMP development <imp-dev(a)salilab.org> > Subject: Re: [IMP-dev] caching advice > Message-ID: > <CADEvLN7wesVz72HK3c9-DQh6DTjcpy8y2hNOZi8kHFZdEyBGbA(a)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(a)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(a)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(a)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(a)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(a)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(a)salilab.org >>>>> https://salilab.org/mailman/listinfo/imp-dev >>>>> >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev(a)salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev(a)salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev(a)salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev(a)salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev June 2012