Enhance sentinel_linear_search doctests with comprehensive examples#14284
Enhance sentinel_linear_search doctests with comprehensive examples#14284JesunAhmadUshno wants to merge 2 commits intoTheAlgorithms:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR primarily aims to enhance documentation and doctest coverage, but it also includes several unrelated typing refactors and small cleanups across the repository.
Changes:
- Expanded
sentinel_linear_search()docstring and doctest examples (4 → 15). - Refactored type parameter declarations in
jump_search()andvalid_input()to use modern generic syntax. - Broadened bipartite-check graph typing to accept generic hashable nodes and updated handling for neighbor-only nodes.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| searches/sentinel_linear_search.py | Adds a more detailed algorithm explanation and many more doctest examples. |
| searches/jump_search.py | Updates generic typing style and removes unused typing imports. |
| machine_learning/linear_discriminant_analysis.py | Updates valid_input generic typing and removes TypeVar. |
| graphs/check_bipatrite.py | Generalizes graph node types and changes semantics for neighbor-only nodes; removes FIXME doctest comments. |
| data_structures/hashing/hash_table_with_linked_list.py | Minor cleanup: uses deque() instead of deque([]). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| def jump_search[T: Comparable](arr: Sequence[T], item: T) -> int: | ||
| """ |
There was a problem hiding this comment.
The PR title/description focuses on doctests for sentinel_linear_search(), but this change set also modifies typing/generics in other modules (e.g., jump_search, LDA valid_input, bipartite checks, hash table). Please update the PR description to reflect these changes or split them into separate PRs so review/rollback scope is clear.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
| >>> is_bipartite_dfs({0: [1, 3], 1: [0, 2], 2: [1, 3], 3: [0, 2], 4: [0]}) | ||
| False | ||
| >>> is_bipartite_dfs({7: [1, 3], 1: [0, 2], 2: [1, 3], 3: [0, 2], 4: [0]}) | ||
| False | ||
|
|
||
| >>> # FIXME: This test should fails with KeyError: 4. | ||
| >>> is_bipartite_dfs({0: [1, 3], 1: [0, 2], 2: [1, 3], 3: [0, 2], 9: [0]}) | ||
| False |
There was a problem hiding this comment.
With the new behavior that neighbor nodes missing from graph are treated as having no outgoing edges, the example is_bipartite_dfs({7: ..., 4: [0]}) appears bipartite under the docstring definition, but the current algorithm returns False because it starts node 4 with an arbitrary color that can conflict with already-colored neighbor-only nodes. Consider choosing the start color based on any already-visited neighbors (or otherwise reconciling components), and update the doctest expected value accordingly.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
| False | ||
| >>> is_bipartite_bfs({7: [1, 3], 1: [0, 2], 2: [1, 3], 3: [0, 2], 4: [0]}) | ||
| False | ||
|
|
||
| >>> # FIXME: This test should fails with KeyError: 4. | ||
| >>> is_bipartite_bfs({0: [1, 3], 1: [0, 2], 2: [1, 3], 3: [0, 2], 9: [0]}) | ||
| False |
There was a problem hiding this comment.
Same issue as DFS: for graphs where some nodes appear only as neighbors (not keys), starting a new BFS component with color 0 can create a false conflict against an already-colored neighbor-only node (e.g., the {7: ..., 4: [0]} example). Initialize the component’s start color based on any already-colored neighbors (and verify consistency), or adjust the doctest/contract so the function’s behavior matches the documented bipartite definition.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
searches/sentinel_linear_search.py
Outdated
| @@ -18,6 +18,11 @@ def sentinel_linear_search(sequence, target): | |||
| :param target: item value to search | |||
| :return: index of found item or None if item is not found | |||
|
|
|||
| The sentinel linear search algorithm works by appending the target value to the | |||
| end of the list before searching. This eliminates the need for boundary checking | |||
| during the loop, as the search is guaranteed to find the target (at minimum, at | |||
| the end where the sentinel is placed). | |||
There was a problem hiding this comment.
The docstring describes sequence as “some sequence”, but the implementation requires a mutable list-like object because it calls append() and pop() and mutates the input (even if it restores it). Please clarify the accepted type (e.g., list/MutableSequence) and explicitly note the temporary mutation, or change the implementation to avoid mutating the caller’s object.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
a2dd3c3 to
c8d6bab
Compare
Summary
Enhanced doctest coverage for
sentinel_linear_search()with 15 comprehensive test examples covering:Changes
python -m doctest -v sentinel_linear_search.pyChecklist