The upper bound ofµicfor the highest reliability factorµof one interchange and a lower bound on the number of interchanges to the targeticseemed not really tight (cf. the end of Section8.5.2). Unfortunately our suspicion was justified, we save only 2% of significant operations and 1% runtime (see Table9.18). We use the bound nonetheless, as we need the number of interchanges as a lower bound anyway and get this tiny improvement for free.
9.7.3 Summary Lower Bounds
Lower bounds on travel time are essential for the algorithm as they enable goal-direction The best performance is the result of using a bidirectional station graph Dijkstra with triangle inequalities and biconnected component pruning on a standard station graph for lower bounds on travel time (in about 16ms) The easy to calculate lower bounds on ticket cost (below 4ms) have a high impact (reducing search time by three quarters). Using the information obtained from the station graph for travel time, lower bounds on the number of interchanges to the target can be calculated in less than 10ms on the interchange graph obtained from unified routes. We get the lower bounds on the interchange reliability for free from the lower bounds on the number of interchanges to the terminal.
The influence of the lower bounds on travel time and interchanges in comparison to the most basic version using lower bounds on the travel time from thestandard station graph without bidirectional Dijkstra and pruning in the preprocessing can be found in the Appendix in TableB.1.
In summary, all our lower bounds can be calculated in about 30ms. The bounds for travel time and number of interchanges to the terminal are used in goal-direction (as we will see in Section9.8.2) and lower bounds for all our criteria improve the technique to dominate labels by labels at the terminal. These decrease the average search speed from about 15 seconds (run without both of these techniques in Table 9.16) to less than 0.5 seconds.
9.8 Priority Queue 149
PQ FIFO Tie- Runtime PQ extracts Labels created
type breaking avg ratio avg ratio avg ratio
in ms in % in % in %
dialF √
412.14 100.00
57,926 100.00 90,921 100.00 heap
binary √
560.59 136.02
4–heap √
526.15 127.66
pairing √
575.06 139.53 heap
binary 487.75 118.35 55,555 95.91 88,841 97.71
4–heap 457.17 110.93 55,469 95.76 88,723 97.58
pairing 527.20 127.92 55,583 95.95 89,042 97.93
4–heap lexi 538.28 130.61 66,876 115.45 100,177 110.18 Table 9.20: The influence of different priority queue types. The heaps were tested with and without FIFO tie-breaking. Additionally the 4–heap with lexicographic smaller relation for comparisons. Runtime and number of significant operations.
for the smaller relation. Although this ordering saves nearly 5% of the extract operations and over 2% of the number of created labels, it does not suffice to make the heaps competitive. The fastest heap (4–heap) still is 10% slower than Dial’s data structure.
Interestingly, perturbing labels with the same value(·) in Dial’s data structure did not improve the number of significant operations.
Lexicographic Lexicographic ordering seems to be a worse choice than the variants using travel time plus weighted number of interchanges as the sorting criterion. Com-paring lexicographic ordering for the 4–heap with the runtime for the same heap with or without FIFO property, we observe a significant increase in the number of significant operations, over 10% in created labels and 15% to 20% in priority queue operations. The runtime is about 18% worse than without FIFO.
Due to this poorer performance we did not consider lexicographic ordering for Dial’s data structure. Note that the adaption of lexicographic ordering to a value function would require the value to be something like
value(A) = (((timeA·11 +icA)·101) +secA)·201 +costA
for the reasonable upper bounds of at most 10 interchanges, 100% reliability and no more than 200eticket cost. So for travel times of no more than two days, a number of 2880·11·101·201≈640 million buckets would be required.
Without goal-direction the performance of lexicographic ordering and weighted sum is nearly identical with a slightly lower number of significant operations and 2,588ms on average for lexicographic compared to 2,620ms for our standard smaller relation.
9.8.2 Weight for Interchanges in Goal-Direction
For the best priority queue (Dial’s data structure) we tested different values for the weight of the number of interchanges (γ∈ {0,5,10,20,30,50,300}). We either used the number of interchanges accumulated so far or this number plus a lower bound on the number of interchanges to the terminal. The resulting runtime and the number of significant operations are given in Table 9.21. First of all we can see that using goal-direction for
Interchanges Runtime PQ extracts Labels created
wage goal- avg ratio avg ratio avg ratio
direction in ms in % in % in %
0 479.14 100.00 69,303 100.00 102,147 100.00
5 425.78 88.86 60,921 87.90 94,977 92.98
√ 422.66 88.21 59,576 85.96 93,113 91.16
10 √ 419.15 87.48 60,723 87.62 94,893 92.90
416.95 87.02 58,582 84.53 91,854 89.92
20 419.25 87.50 61,116 88.19 95,539 93.53
√F
412.14 86.01 57,926 83.58 90,921 89.01
30 √ 429.92 89.73 62,040 89.52 96,897 94.86
421.12 87.89 58,202 83.98 91,211 89.29
50 439.13 91.65 64,408 92.94 100,300 98.19
√ 428.55 89.44 59,007 85.14 92,039 90.10 300 √ 511.67 106.79 80,907 116.74 123,275 120.68 459.46 95.89 63,112 91.07 96,763 94.73
Table 9.21: The influence of different weights for the number of interchanges in the smaller relation with and without using goal-direction for interchanges as well.
the number of interchanges as well always improves the search speed. The wage of choice seems to be γ = 20. It achieves the lowest number of labels created and extracted and likewise the fastest search times. We save about 14% of the processing time with this choice ofγ.
If we choose the real large valueγ= 300 we are essentially using the number of inter-changes as our most important criterion in goal-direction and travel time as a secondary criterion. However, this alone does not seem to be a good move.
9.8.3 Reordering the Priority Queue
The strategy to reorder the priority queue once the first optimal connection is found was presented in Section8.8.3. We start using goal-direction according to the criterion travel time using the weightγ= 20 as determined in the previous section. As soon as the first (and fastest) connection is found, we change the ordering in the priority queue. For the remainder of the search we useγ= 300, making the number of interchanges the dominant criterion and travel time the secondary one. In Table9.22we see the resulting runtimes and the number of significant operations in comparison to the variants using eitherγ= 20 orγ= 300 throughout the whole search.
Naturally, the standard version and reorder find the first and fastest solution at the same time. When the first solution is found, about 19,000 labels are stored in the priority queue. These have to be reordered according to the new sorting criterion. The second result inreorder is obtained earlier than in the standard version. Remember that these results are not identical, reorder determines the results with the least number of inter-changes as result number two. In comparison the version using goal-direction according to the number of interchanges from the beginning, finds its first (and second) connection much earlier. In spite of that the total runtime is higher. Even with the additional cost for reordering, variantreorder achieves a runtime between the two. Unfortunately,
goal-9.8 Priority Queue 151
Weight for Runtime PQ extracts Labels created
interchanges avg ratio 1st 2nd avg ratio avg ratio
γ in ms in % in % in %
20F 412.14 100.00 7,284 9,772 57,926 100.00 90,921 100.00 207→300 448.78 108.89 7,284 8,738 61,283 105.80 94,733 104.19 300 459.46 111.48 3,081 5,070 63,112 108.95 96,763 106.43 Table 9.22: Strategy reordering the priority queue compared to the versions with the initial and final weight for interchanges. Runtime and number of significant operations in total and until the first and second optimal connection were found.
direction according to the number of interchanges, either completely or after reordering does not pay off, as the number of significant operations, as well as runtime, is worse than that of the standard version.
9.8.4 Decreasing the Number of Labels in the PQ
In this section we will study the techniques to skip departure nodes (skip) presented in Section8.6.2, bypass departure nodes (bypass) from Section8.6.3and avoid inserting min-imum labels (avoid) introduced in Section8.8.4. Runtime and the number of significant operations can be found in Table9.23.
Techniques skip and bypass Both do not enter departure nodes into the priority queue, therefore they have nearly identical numbers of extract operations. However, the labels are still created inskip. Even around 4% more are created as the sequence of labels is different from the extraction sequence in the standard version. Once skip decides to take a train, its departure event is processed immediately after the entering edge. Since the departure has one interchange more, in the standard version another label might be processed in between.
Bypassonly saves 10% of the runtime although saving roughly 30% of the extractions and 18.5% of the label creations. This is due to the fact, that the combined edge types are harder to evaluate than e.g. a stay-in-train edge. It is simply always available and no checks have to be performed and only the travel time and nothing else of the new label has to be updated. Consequently, the average work per label creation or edge inspection increases.
Labels Runtime PQ extracts created
Strategy not inserted avg ratio avg ratio avg ratio
avg in % in ms in % in % in %
noneF - 0.00 412.14 100.00 57,926 100.00 90,921 100.00 skip 21,052 36.34 434.37 105.39 40,304 69.58 94,633 104.08 bypass - 0.00 370.71 89.95 40,624 70.13 74,057 81.45 avoid 8,952 15.45 410.14 99.52 49,054 84.68 91,106 100.20 Table 9.23: The influence of techniques: skip departure nodes, bypass departure nodes and avoid inserting minimum labels. Runtime, number of significant operations, and the number of labels that were not inserted into the priority queue.
Technique avoid Avoiding about 15% of the operations on the priority queue does not result in reduced computation time. This is due to the additional comparisons and the fact that using a FIFO queue for the labels that are equal or better than the current minimum in the queue is not much different from (and thus not faster than) determining and using the right FIFO queue in an array of FIFO queues in Dial’s data structure.