-
Notifications
You must be signed in to change notification settings - Fork 0
feat(parallelsearch): per-ID PEP for transient databases + family-aware organism detection #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: ManySearchTask
Are you sure you want to change the base?
Changes from all commits
3bcf4c3
fda60e7
2cc6b1d
9f6f5d6
28b3d86
a120dde
4d70e18
797ff65
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Issue: this PR is expanding Original design intent: ParallelSearch already tends to preserve the baseline engine behavior and add transient-specific wrappers where needed, e.g. Proposed change: introduce
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done in 797ff65. Extracted |
Large diffs are not rendered by default.
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Issue: a large portion of the original search loop was rewritten to support batching, flattened scoring data, scorer providers, and sinks. Even if the performance motivation is valid, the amount of structural change makes the transient search engine much farther from the original simple wrapper. Original design intent: Proposed change: keep the optimization work, but contain it more aggressively: hide batching/helper types as internal implementation details, preserve direct use of
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one belongs to the stacked Agreed on the direction: keep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best approach would be to break out a TransientPEPAnalysisEngine : PEPAnalysisEngine so that we leave the old unchanged and have our derived class to the special work of caching the results from baseline. This pattern is used throughout the parallel search.
May require moving some things from private to protected
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 797ff65. Extracted
TransientPepAnalysisEngine : PepAnalysisEngineunderEngineLayer/ParallelSearch. It owns the train-once base model, the reuse / apply-to-transient path, and the backgroundPEP -> PEP_QValuecurve.PepAnalysisEngineis back to just the standard cross-validated workflow — the only seam movedprivate -> protectedwas_randomSeed. MirrorsTransientProteinParsimonyEngine/TransientProteinScoringAndFdrEngineas you suggested.