Weight as a function of distance at source
Hi,
Looking at BGL implementations, weight, compare and combine are used in
examine edge(e) as
compare(combine(old_distance, get(weight, e)), old_distance)
Additionally, old_distance = m_zero to check for negative weights etc.
In my implementation, edges have a bundled property
struct EdgeProp {
Distance weight(Distance start) { ... }
};
that returns the cumulative weight on iterating over the edge given a start
distance.
To use this, I should be able to pass a combine function of the form
[]<typename BinaryFunction>(DistanceType d, BinaryFunction f) { return
f(d); }
However, this approach falls apart.
I've tried putting together a formal example here, but not sure why this
fails. (My actual use case is where weights represent nodes in a transport
system and for a person arriving at a vertex at some time Tx, there is a
variable weight of using the next outbound transport = waiting_time +
travel_time, where waiting_time is a function of Tx
#include
My actual use case is where weights represent nodes in a transport system and for a person arriving at a vertex at some time Tx, there is a variable weight of using the next outbound transport = waiting_time + travel_time, where waiting_time is a function of Tx.
That sounds like you intend to calculate a *dynamic* shortest path, which is not what Dijkstra's algorithm does for you. I know it doesn't answer your question, but I think it is more pertinent. Kind regards, Alex
In a way, yes. But I don't see where dijkstra would fail here given the weights are always positive. A regular bfs from a given start time should populate the distances to all nodes, identical to dijkstra On Fri, Dec 18, 2020 at 6:39 AM Alex Hagen-Zanker < a.hagen-zanker@surrey.ac.uk> wrote:
My actual use case is where weights represent nodes in a transport system and for a person arriving at a vertex at some time Tx, there is a variable weight of using the next outbound transport = waiting_time + travel_time, where waiting_time is a function of Tx.
That sounds like you intend to calculate a *dynamic* shortest path, which is not what Dijkstra's algorithm does for you.
I know it doesn't answer your question, but I think it is more pertinent.
Kind regards, Alex
In a way, yes. But I don't see where dijkstra would fail here given the weights are always positive. A regular bfs from a given start time should populate the distances to all nodes, identical to dijkstra
I think you are right, as long as you cannot get a better connection by arriving later.
The combine function is supposed to combine a distance and a weight, typically these are the same type. Perhaps you are better off incorporating the waiting time in your weight property map.
You might be able to do this using the function_property_map (https://www.boost.org/doc/libs/1_59_0/libs/property_map/doc/function_propert... ).
Or to create your own property map, similar to this:
template
My actual use case is where weights represent nodes in a transport system and for a person arriving at a vertex at some time Tx, there is a variable weight of using the next outbound transport = waiting_time + travel_time, where waiting_time is a function of Tx.
That sounds like you intend to calculate a *dynamic* shortest path, which is not what Dijkstra's algorithm does for you. I know it doesn't answer your question, but I think it is more pertinent. Kind regards, Alex
participants (2)
-
Alex Hagen-Zanker
-
Amit Prakash Ambasta