Comments (5)
Can you give an example for such a method?
from fast_paths.
For instance, old:
// prepare the graph for fast shortest path calculations. note that you have to do this again if you want to change the
// graph topology or any of the edge weights
let fast_graph = fast_paths::prepare(&input_graph);
// calculate the shortest path between nodes with ID 8 and 6
let shortest_path = fast_paths::calc_path(&fast_graph, 8, 6);
New:
let fast_graph = input_graph.prepare_fast_graph();
let shortest_path = fast_graph.calc_path(8, 6);
from fast_paths.
let fast_graph = input_graph.prepare_fast_graph();
That makes little sense to me. The input graph is just a data structure and has nothing to do with the fast graph preparation or at least I see no reason to couple the input graph to the fast graph preparation like this.
let shortest_path = fast_graph.calc_path(8, 6);
This might be reasonable, but what about the usage pattern with PathCalculator
? The calc_path
calculator really belongs to the PathCalculator
class, why should it be available via fast_graph
as well?
I don't know I do not see a big improvement in changing these the way you propose. But maybe you can explain a bit how this would help or make things easier for your use case? And maybe have a second look at lib.rs
. These fast_paths::xyz
functions are really just high level util functions that use the underlying classes of this crate. Maybe you can just use the library classes directly?
from fast_paths.
Changing the prepare_fast_graph
method to be an instance method of input_graph
does not make it coupled. It is already coupled because it requires taking in input_graph
. Rather, it makes this coupling more obvious, and thus easier to read.
The PathCalculator
should ideally be redone as well. The fast_graph
is passed in both when the calculator is created, and also when the path is calculated. Imo it would make a lot more sense for it to only be passed in once. It also makes it harder for the programmer to make a mistake - what if they pass one fast_graph
in when creating the calculator, and pass in a different fast_graph
when calculating the path?
from fast_paths.
Changing the prepare_fast_graph method to be an instance method of input_graph does not make it coupled. It is already coupled because it requires taking in input_graph. Rather, it makes this coupling more obvious, and thus easier to read.
Hm, prepare_fast_graph()
is already coupled to the input graph yes, but not the other way around. Its just a data structure and it does not depend on its users or client code. Imagine there was more code related to input graph. Maybe there would be some routines to do some pre-processing of the graph, or some code to store it on disk, serialize it etc. With this logic input graph would have all these methods: input_graph.pre_process
, input_graph.save_to_disk
etc. So everything would be coupled to it. It would be like attaching all kinds of methods to Vec
just because you can do many things with a Vec
.
The fast_graph is passed in both when the calculator is created, and also when the path is calculated.
The path calculator constructor only takes an integer input (the number of nodes of the graph). But its true that the number of nodes passed into the constructor must match the actual number of nodes of the fast graph used in calc_paths
later on. This is not ideal, yes. But this brings up the question who "owns" the fast graph instance and since there are typically multiple path calculator instances (e.g. one per thread) I did not think path calculator should own the fast graph. Or would you keep just some kind of reference to the fast graph (passed via the constructor)? I think I tried this briefly but felt like adding the complexity of lifetimes and borrowing objects was not worth it.
what if they pass one fast_graph in when creating the calculator, and pass in a different fast_graph when calculating the path?
This case is covered by this assert. So there will be an error indicating the wrong usage pattern:
fast_paths/src/path_calculator.rs
Lines 61 to 65 in f00b621
from fast_paths.
Related Issues (19)
- Get rid of compiler warnings due to unused code in floyd_warshall.rs HOT 3
- usize does not work well for de/serialization. HOT 4
- CH improve amount of created shortcuts HOT 9
- bidijkstra stall-on-demand HOT 21
- Possible perf regression with Rust 1.45 HOT 4
- Extremely high memory usage when generating fast graph HOT 8
- Copy and Clone Traits HOT 3
- Rust 1.51.0 warning: panic message is not a string literal HOT 1
- Dual licensing MIT/Apache 2.0 HOT 1
- ShortestPath PartialEq ignores nodes
- Improve preparation time
- Why does the preparation time vary so much for different maps? HOT 13
- Possibly wrong path? HOT 3
- What would it take to support tiled routing graphs? HOT 3
- Add a way to get all nodes in a radius HOT 7
- The dijkstra's implementation should be bidirectional HOT 2
- Document how to run the benchmarks HOT 6
- Huge performance difference in terms of running time HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fast_paths.