Closed
Conversation
Add test_edge_map.py with tests that demonstrate the desired behavior: - edge_map should operate on edge labels (edge_id), not indices - edge_map should validate that target values exist in the graph - edge_map should allow merging multiple edges to a single label These tests currently fail due to the current implementation mixing segment indices with edge labels. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Fix the edge_map implementation to properly handle the abstraction between: - Internal segment indices (0..E-1) used for array operations - External edge labels (edge_id) used for user-facing API Key changes: - Create mappings between edge_ids and indices at function start - Apply edge_map to labels (edge_ids) only, not indices - Use original indices for all internal operations (_calculate_linear_position) - Return mapped edge_ids in final output (track_segment_id column) - Support string and arbitrary target values for edge relabeling - Invalid source keys are ignored (maintaining backward compatibility) Updated _calculate_linear_position to use segment indices directly instead of trying to convert them back to edge_ids, eliminating the KeyError issue. All existing edge_map tests now pass, including string values and merging scenarios. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Add proper validation to reject invalid source edge_ids in edge_map to prevent user confusion and provide clear error messages. Changes: - Validate that all edge_map keys exist in the graph - Raise ValueError with helpful message listing valid edge_ids - Update tests to expect validation errors instead of silent ignoring - Maintain support for arbitrary target values (strings, new IDs, etc.) This improves user experience by catching configuration errors early rather than silently ignoring invalid mappings. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
edge_mapsemantics that separate segment indices from edge labelsedge_mapwas applied at the wrong abstraction leveledge_mapis applied only to edge labels (edge_id) for final outputKey Changes
edge_mapto labels, use indices for internal operations_calculate_linear_position: Use segment indices directly instead of converting back to edge_idsTest Results
edge_maptests pass (10/10)Technical Details
The fix addresses the original bug where:
find_nearest_segment()returns segment indices (0, 1, 2, ...)edge_mapwas incorrectly applied to these indices_calculate_linear_position()expected edge_ids but received indices, causing KeyErrorNow:
edge_ids = edge_id_by_index[seg_idx]edge_mapto edge_ids:mapped_edge_ids = [edge_map.get(eid, eid) for eid in edge_ids]🤖 Generated with Claude Code