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, wrote:
> Send IMP-dev mailing list submissions to
>
>
> 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
>
>
> You can reach the person managing the list at
>
>
> 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 <>
> To: List for IMP development <>
> Subject: Re: [IMP-dev] caching advice
> Message-ID:
> <CAN4WCj=>
> 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 <> 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 <> 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 <> 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 <>
>>>> 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
>>>>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>
>>
>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 7 Jun 2012 12:22:24 -0700
> From: Daniel Russel <>
> To: List for IMP development <>
> Subject: Re: [IMP-dev] caching advice
> Message-ID:
> <>
> 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 <> 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 <> 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 <>
>> 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 <>
>> 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 <>
>>>>> 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
>>>>>
>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>
>>>> _______________________________________________
>>>> IMP-dev mailing list
>>>>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://salilab.org/mailman/private/imp-dev/attachments/20120607/c42376d1/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 08 Jun 2012 09:40:10 +0200
> From: Yannick SPILL <>
> To: List for IMP development <>
> Subject: Re: [IMP-dev] caching advice
> Message-ID: <>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 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 <
>> <">mailto:>> 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 <
>> <">mailto:>> 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
>> < <">mailto:>> 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
>> < <">mailto:>> 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
>> < <">mailto:>>
>>>>> 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
>>>>> <">mailto:>
>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>
>>>> _______________________________________________
>>>> IMP-dev mailing list
>>>> <">mailto:>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>> <">mailto:>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>> <">mailto:>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>> <">mailto:>
>> https://salilab.org/mailman/listinfo/imp-dev
>>
>>
>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> https://salilab.org/mailman/listinfo/imp-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://salilab.org/mailman/private/imp-dev/attachments/20120608/99af7319/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev
>
>
> End of IMP-dev Digest, Vol 55, Issue 2
> **************************************