-
Notifications
You must be signed in to change notification settings - Fork 2
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
Implement chromosomes in sample_resolve #107
Conversation
WalkthroughThe recent updates to the GeneticInheritanceGraphLibrary focus on enhancing the handling of genetic data. By incorporating Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
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.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (2)
- GeneticInheritanceGraphLibrary/graph.py (2 hunks)
- GeneticInheritanceGraphLibrary/tables.py (1 hunks)
Additional comments: 3
GeneticInheritanceGraphLibrary/graph.py (3)
- 8-8: The addition of
defaultdict
from thecollections
module is appropriate for the use case described in the PR objectives and the AI-generated summary. This import is used effectively in the modification of thestack
declaration to handle intervals associated with chromosomes more efficiently.- 323-326: The modification of the
stack
declaration to usedefaultdict
for intervals is a significant improvement. It allows for a more efficient handling of intervals associated with chromosomes, aligning with the PR's objectives. However, it's important to ensure that the use ofdefaultdict
and theportion
library does not introduce any unintended side effects, especially in terms of performance and memory usage.- 329-367: The changes within the loop for handling chromosomes and intervals are well-implemented. The use of
defaultdict
along with theportion
library for interval handling is a clever approach that should improve the efficiency of thesample_resolve
method. However, there are a few points to consider:
- Ensure that the handling of inversions (
is_inversion
) and the transformation of intervals (transform_interval
) are thoroughly tested, especially for edge cases.- The nested loop structure and the use of intersection (
&
) operation on intervals could potentially be optimized further. Consider profiling this section to identify any performance bottlenecks.- The addition of new parameters (
child_chromosome
,parent_chromosome
) to theadd_iedge_row
method call aligns with the PR's objectives of incorporating chromosome information. Ensure that these changes are consistent across all relevant method calls in the library.Overall, these changes significantly enhance the library's capability to model genetic relationships and inheritance patterns more precisely by introducing chromosome information into its core functionalities.
def chromosomes_for_child(self, u): | ||
""" | ||
Iterate over the chromosome numbers for a given child ID | ||
""" | ||
|
||
return self._id_range_for_child.get(u, {}).keys() | ||
|
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.
The method chromosomes_for_child
correctly implements the functionality to iterate over chromosome numbers for a given child ID. However, it's important to ensure that the method's return type is consistent and well-documented. Since dict.keys()
returns a view object in Python 3, consumers of this method might expect a list or another iterable that supports indexing. Consider explicitly converting the keys to a list if a specific order or index-based access is required by the callers.
To improve clarity and ensure the method's return type aligns with potential usage scenarios, you might consider converting the keys to a list, especially if the order of chromosomes is significant or if the callers expect a list. If the order is not important and the callers only need to iterate over the chromosomes, the current implementation is sufficient but should be documented.
- return self._id_range_for_child.get(u, {}).keys()
+ return list(self._id_range_for_child.get(u, {}).keys())
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
def chromosomes_for_child(self, u): | |
""" | |
Iterate over the chromosome numbers for a given child ID | |
""" | |
return self._id_range_for_child.get(u, {}).keys() | |
def chromosomes_for_child(self, u): | |
""" | |
Iterate over the chromosome numbers for a given child ID | |
""" | |
return list(self._id_range_for_child.get(u, {}).keys()) |
33587a5
to
22f7984
Compare
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.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (7)
- GeneticInheritanceGraphLibrary/constants.py (1 hunks)
- GeneticInheritanceGraphLibrary/graph.py (6 hunks)
- GeneticInheritanceGraphLibrary/tables.py (5 hunks)
- tests/conftest.py (6 hunks)
- tests/gigutil.py (1 hunks)
- tests/test_graph.py (2 hunks)
- tests/test_tables.py (4 hunks)
Files skipped from review as they are similar to previous changes (2)
- GeneticInheritanceGraphLibrary/graph.py
- GeneticInheritanceGraphLibrary/tables.py
Additional comments: 10
GeneticInheritanceGraphLibrary/constants.py (1)
- 9-9: The addition of
NODE_IS_RE = 1 << 19
in theConst
class is noted as mainly for testing purposes. It's important to ensure that this new constant is appropriately used throughout the tests and does not inadvertently affect the production code or other parts of the codebase where it's not intended to be used.Verification successful
The search confirmed that
NODE_IS_RE
is only declared in theconstants.py
file and is not used elsewhere in the codebase outside of test directories. This aligns with the intended purpose of the constant being mainly for testing. No issues were found regarding its usage.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of NODE_IS_RE in non-test files to ensure it's used appropriately. rg 'NODE_IS_RE' --glob '!tests/*'Length of output: 124
tests/conftest.py (5)
- 6-7: The imports of
Const
andValidFlags
fromGeneticInheritanceGraphLibrary.constants
are correctly placed and necessary for the new testing fixtures introduced in this file. Good practice in organizing imports at the beginning of the file.- 49-70: The
trivial_gig
fixture is well-constructed for creating a basic genetic inheritance graph for testing purposes. It correctly uses theNODE_IS_SAMPLE
constant and theiedge
helper function to define nodes and edges, demonstrating good practice in leveraging constants and utilities for clarity and maintainability.- 124-155: The
multi_chromosome_gig
fixture provides a detailed setup for testing the handling of multiple chromosomes in genetic inheritance graphs. The use of additional parameters in theiedge
function, such aschild_chromosome
andparent_chromosome
, is well-executed, ensuring thorough testing of the library's functionality in complex scenarios.- 206-250: The
all_sv_types_1re_gig
fixture is significant for testing the handling of structural variations and recombination events in genetic inheritance graphs. The integration of the newly addedNODE_IS_RE
constant to denote a recombination event node is well-executed, showcasing thoughtful testing design to cover complex scenarios.- 203-260: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [253-268]
The
all_sv_types_2re_gig
fixture extends testing scenarios to include genetic inheritance graphs with two recombination events, using theNODE_IS_RE
constant to denote separate recombination event nodes. This comprehensive testing design is crucial for ensuring the library's robustness in handling complex genetic inheritance patterns.Also applies to: 269-269
tests/gigutil.py (1)
- 23-27: The modification to the
iedge
function to accept additional keyword arguments (**kwargs
) enhances its flexibility and utility in creating interval edges (iedges) with more detailed configurations. This change is particularly beneficial for testing scenarios that require specific edge attributes, as demonstrated in theconftest.py
file.tests/test_graph.py (1)
- 296-401: The newly added test methods
test_all_svs_no_re_sample_resolve
,test_all_svs_1re_sample_resolve
,test_all_svs_2re_sample_resolve
, andtest_sample_resolve_with_chromosomes
effectively cover various scenarios involving sample resolution with different configurations, including recombination nodes and multiple chromosomes. These tests are crucial for verifying the correct behavior of edge splitting, trimming, and handling of chromosomes in the graph structure. However, there are a few areas that could be improved for clarity and maintainability:
Comments and Documentation: Adding more detailed comments explaining the setup and expected outcomes of each test case can greatly aid in understanding the test's purpose and the specific scenarios it covers. This is especially important for complex tests like
test_all_svs_2re_sample_resolve
andtest_sample_resolve_with_chromosomes
, where the logic involves handling multiple chromosomes and recombination nodes.Refactoring for Reusability: There seems to be a pattern of asserting conditions on iedges in multiple tests (e.g., lines 302-315, 321-335, 347-362, 383-401). Consider refactoring these assertions into helper methods to reduce code duplication and improve readability. For example, a method that takes an iedge and expected properties as parameters and performs the assertions could be reused across different tests.
Testing Edge Cases: While the tests cover a good range of scenarios, it would be beneficial to include tests for edge cases, such as empty graphs, graphs with a single node, or scenarios with extreme chromosome numbers or positions. These edge cases can help ensure the robustness of the sample resolution logic under unusual conditions.
Performance Considerations: If not already done, it might be useful to monitor the performance of these tests, especially for scenarios involving large graphs or complex recombination patterns. Ensuring that the tests run efficiently can help maintain a fast development cycle.
Overall, the addition of these tests is a significant step forward in ensuring the correctness and reliability of the sample resolution functionality in the context of genetic inheritance graphs. With some refinements for clarity, reusability, and coverage of edge cases, the test suite will be even more robust.
tests/test_tables.py (2)
- 258-276: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [251-289]
The parameter
all_sv_types_re_gig
has been renamed toall_sv_types_2re_gig
in multiple test functions. This change is consistent across the file and improves the clarity of the parameter's purpose, which seems to be related to handling genetic inheritance graphs with specific structural variations. The renaming does not appear to affect the logic or functionality of the tests.
- 492-494: The modifications to the error messages in the
test_add_iedge_row_fail_primary_order_child_time
function enhance clarity and specificity, making it easier for developers to understand the nature of the error when the test fails. This is a good practice for writing maintainable and understandable tests.
Starts to address #103. No tests yet.
Summary by CodeRabbit