search

salilab / imp

The Integrative Modeling Platform
https://integrativemodeling.org
GNU General Public License v3.0
73 stars 30 forks source link

RestraintSet vs ScoringFunction #529

Closed yannickspill closed 11 years ago

yannickspill commented 11 years ago

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

drussel commented 11 years ago

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529 .

barakr commented 11 years ago

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25022492 .

Barak

drussel commented 11 years ago

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492> .

Barak

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25024449 .

yannickspill commented 11 years ago

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492> .

Barak

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25024449 .

— Reply to this email directly or view it on GitHub.

drussel commented 11 years ago

Well, the papers/grants tend to use restraint for a scoring function term and scoring function for the whole thing, so neither of them is a new term. And at this point, replacing the term "Restraint" seems more work than worthwhile.

On Tue, Sep 24, 2013 at 11:38 AM, Yannick notifications@github.com wrote:

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492> .

Barak

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25024449> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25031111 .

yannickspill commented 11 years ago

Yes definitely. What i meant is let's rename scoringfunction to evaluator or restraintsets

On 24 sept. 2013, at 21:02, drussel notifications@github.com wrote:

Well, the papers/grants tend to use restraint for a scoring function term and scoring function for the whole thing, so neither of them is a new term. And at this point, replacing the term "Restraint" seems more work than worthwhile.

On Tue, Sep 24, 2013 at 11:38 AM, Yannick notifications@github.com wrote:

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick notifications@github.com wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492> .

Barak

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25024449> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25031111 .

— Reply to this email directly or view it on GitHub.

drussel commented 11 years ago

While, I have to admit Evaluator is nice because it talks about what it does (in fact that was, I believe, the original name I used for it), I don't really see a benefit to making up a new term for scoring function which is the concept from the integrative modeling formalism it implements.

In papers we tend to talk about the model -> kernel::Model particles ->kernel::Particle scoring function terms/restraints -> kernel::Restraint the scoring function -> kernel::ScoringFunction a sampling procedure ~> kernel::Sampler (which was not very successful)

On Tue, Sep 24, 2013 at 12:08 PM, Yannick notifications@github.com wrote:

Yes definitely. What i meant is let's rename scoringfunction to evaluator or restraintsets

On 24 sept. 2013, at 21:02, drussel notifications@github.com wrote:

Well, the papers/grants tend to use restraint for a scoring function term and scoring function for the whole thing, so neither of them is a new term. And at this point, replacing the term "Restraint" seems more work than worthwhile.

On Tue, Sep 24, 2013 at 11:38 AM, Yannick notifications@github.com wrote:

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel notifications@github.com

wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick < notifications@github.com> wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492> .

Barak

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25024449> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25031111> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25033537 .

barakr commented 11 years ago

what I always found confusing is that we have both Score class and ScoringFunction class, and Restraint in the middle. What each of them means feel kinda arbitrary :)

On Tue, Sep 24, 2013 at 12:20 PM, drussel notifications@github.com wrote:

While, I have to admit Evaluator is nice because it talks about what it does (in fact that was, I believe, the original name I used for it), I don't really see a benefit to making up a new term for scoring function which is the concept from the integrative modeling formalism it implements.

In papers we tend to talk about the model -> kernel::Model particles ->kernel::Particle scoring function terms/restraints -> kernel::Restraint the scoring function -> kernel::ScoringFunction a sampling procedure ~> kernel::Sampler (which was not very successful)

On Tue, Sep 24, 2013 at 12:08 PM, Yannick notifications@github.com wrote:

Yes definitely. What i meant is let's rename scoringfunction to evaluator or restraintsets

On 24 sept. 2013, at 21:02, drussel notifications@github.com wrote:

Well, the papers/grants tend to use restraint for a scoring function term and scoring function for the whole thing, so neither of them is a new term. And at this point, replacing the term "Restraint" seems more work than worthwhile.

On Tue, Sep 24, 2013 at 11:38 AM, Yannick notifications@github.com wrote:

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr notifications@github.com

wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel < notifications@github.com>

wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick < notifications@github.com> wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25022492>

.

Barak

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25024449> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25031111> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25033537> .

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25034504 .

Barak

drussel commented 11 years ago

Yup, they are kind of arbitrary. Just to be picky though, there is no Score class, just PairScores, TripletScores etc, although our naming convention kind of suggests their would be). And the is IMP.score_functor module... But at least some of the arbitrary names have been used lots and lots of times....

On Tue, Sep 24, 2013 at 12:57 PM, barakr notifications@github.com wrote:

what I always found confusing is that we have both Score class and ScoringFunction class, and Restraint in the middle. What each of them means feel kinda arbitrary :)

On Tue, Sep 24, 2013 at 12:20 PM, drussel notifications@github.com wrote:

While, I have to admit Evaluator is nice because it talks about what it does (in fact that was, I believe, the original name I used for it), I don't really see a benefit to making up a new term for scoring function which is the concept from the integrative modeling formalism it implements.

In papers we tend to talk about the model -> kernel::Model particles ->kernel::Particle scoring function terms/restraints -> kernel::Restraint the scoring function -> kernel::ScoringFunction a sampling procedure ~> kernel::Sampler (which was not very successful)

On Tue, Sep 24, 2013 at 12:08 PM, Yannick notifications@github.com wrote:

Yes definitely. What i meant is let's rename scoringfunction to evaluator or restraintsets

On 24 sept. 2013, at 21:02, drussel notifications@github.com wrote:

Well, the papers/grants tend to use restraint for a scoring function term and scoring function for the whole thing, so neither of them is a new term. And at this point, replacing the term "Restraint" seems more work than worthwhile.

On Tue, Sep 24, 2013 at 11:38 AM, Yannick notifications@github.com

wrote:

In that case to be consistent we should switch from Restraint to ScoringTerm or alike. I'm more in favor of evaluator and drop the reference to scoring. There are already so many terms in IMP let's try to avoid new ones!

On 24 sept. 2013, at 19:37, drussel notifications@github.com wrote:

ScoringFunctionEvaluator (or just Evaluation) might be a good name. It has the role of what we call a scoring function in papers, which was the motivation for the name.

On Tue, Sep 24, 2013 at 10:19 AM, barakr < notifications@github.com>

wrote:

To clarify the distinction, would "ScoreEvaluator" be a more accurate name than ScoringFunction (and then, "IncrementalScoreEvaluator", "RestraintsScoreEvaluator", etc.)? Or even omit Score / Scoring from the class name altogether also to prevent confusion with Score class, and, assuming score evaluation is always over restraints (is that true?) - just call it "RestraintsEvaluator", "IncrementalRestraintsEvaluator" etc.". And then, simulator->get_restraints_evaluator->evaluate().

On Tue, Sep 24, 2013 at 9:55 AM, drussel < notifications@github.com>

wrote:

Yeah, they conceivably be merged, although they have different roles. One is for a users to help keep track of things (eg composing RestraintSets which can't be done with scoring functions), and another is to efficiently perform the scoring operation in one of a variety of ways (eg core::IncrementalScoringFunction or not).

On Tue, Sep 24, 2013 at 8:09 AM, Yannick < notifications@github.com> wrote:

What's the difference between a RestraintSet and a ScoringFunction? I understand that, conceptually, one is a bunch of restraints with the intent of grouping similar restraints together, while the other one is focused on scoring, but concretely, they both contain restraints and both can be evaluated to yield a score. So, why keep both?

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529> .

— Reply to this email directly or view it on GitHub<

https://github.com/salilab/imp/issues/529#issuecomment-25022492>

.

Barak

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25024449> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25031111> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25033537> .

— Reply to this email directly or view it on GitHub< https://github.com/salilab/imp/issues/529#issuecomment-25034504> .

Barak

— Reply to this email directly or view it on GitHubhttps://github.com/salilab/imp/issues/529#issuecomment-25037156 .