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
>
_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev