Information
- rustworkx version: 0.17.1
- Python version: -
- Rust version: 1.85
- Operating system: macOS
What is the current behavior?
longest_path allows the edge-weighting function to return PartialOrd values (like f64), but doesn't contractually define what happens if two unordered scores appear. At worst this will cause a panic similar to #1579, but more realistically, any path including the unordered values would be silently suppressed from the calculations.
What is the expected behavior?
The behaviour should be well-defined. Since we return Ok(None) if there is no defined longest path due to the graph not being a DAG, it seems reasonable that we should also return Ok(None) if the longest path isn't defined because there's no clear definition of "longest".
Steps to reproduce the problem
For example:
let mut graph = DiGraph::<(), ()>::new();
let mut prev = graph.add_node(());
for _ in 0..4 {
let cur = graph.add_node(());
graph.add_edge(prev, cur, ());
prev = cur;
}
// If the score function returns unordered scores, there is no "longest" path.
assert_eq!(
longest_path(&graph, |_| Ok::<_, std::convert::Infallible>(f64::NAN)),
Ok(None),
);currently this assertion would fail and return something like Ok(Some((vec![4], 0.0))), which is neither a complete path nor a valid score.
Information
What is the current behavior?
longest_pathallows the edge-weighting function to returnPartialOrdvalues (likef64), but doesn't contractually define what happens if two unordered scores appear. At worst this will cause a panic similar to #1579, but more realistically, any path including the unordered values would be silently suppressed from the calculations.What is the expected behavior?
The behaviour should be well-defined. Since we return
Ok(None)if there is no defined longest path due to the graph not being a DAG, it seems reasonable that we should also returnOk(None)if the longest path isn't defined because there's no clear definition of "longest".Steps to reproduce the problem
For example:
currently this assertion would fail and return something like
Ok(Some((vec![4], 0.0))), which is neither a complete path nor a valid score.