Improved Bounds for Open Online Dial-a-Ride on the Line
Alexander Birx, Yann Disser, Kevin Schewior

TL;DR
This paper establishes a new lower bound of 2.0585 and improves the upper bound to 2.6662 for the competitive ratio of the open online Dial-a-Ride problem on the line, advancing theoretical understanding.
Contribution
It provides the first strict separation between online Dial-a-Ride and TSP on the line and tightens the bounds for the problem's competitive ratio.
Findings
Lower bound of 2.0585 on competitive ratio
Improved upper bound to 2.6662
Analysis of the algorithm is tight
Abstract
We consider the open, non-preemptive online Dial-a-Ride problem on the real line, where transportation requests appear over time and need to be served by a single server. We give a lower bound of 2.0585 on the competitive ratio, which is the first bound that strictly separates online Dial-a-Ride on the line from online TSP on the line in terms of competitive analysis, and is the best currently known lower bound even for general metric spaces. On the other hand, we present an algorithm that improves the best known upper bound from 2.9377 to 2.6662. The analysis of our algorithm is tight.
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Taxonomy
TopicsOptimization and Search Problems · Smart Parking Systems Research · Transportation and Mobility Innovations
Improved Bounds for Open Online Dial-a-Ride on the Line111This work was supported by the ‘Excellence Initiative’ of the German Federal and State Governments and the Graduate School CE at TU Darmstadt.
Alexander Birx
Institute of Mathematics and Graduate School CE, TU Darmstadt, Germany.
Yann Disser
Institute of Mathematics and Graduate School CE, TU Darmstadt, Germany.
Kevin Schewior Supported by the DAAD within the PRIME program using funds of BMBF and the EU Marie Curie Actions.
Institut für Informatik, Technische Universität München, Garching, Germany.
Abstract
We consider the open, non-preemptive online Dial-a-Ride problem on the real line, where transportation requests appear over time and need to be served by a single server. We give a lower bound of on the competitive ratio, which is the first bound that strictly separates online Dial-a-Ride on the line from online TSP on the line in terms of competitive analysis, and is the best currently known lower bound even for general metric spaces. On the other hand, we present an algorithm that improves the best known upper bound from to . The analysis of our algorithm is tight.
1 Introduction
We consider the online Dial-a-Ride problem on the line, where transportation requests appear over time and need to be transported to their respective destinations by a single server. More precisely, each request is of the form and appears in position along the real line at time and needs to be transported to position . The server starts at the origin, can move at unit speed, and has a capacity that bounds the number of requests it can carry simultaneously. The objective is to minimize the completion time, i.e., the time until all requests have been served. In this paper, we focus on the non-preemptive and open setting, where the former means that requests can only be unloaded at their destinations, and the latter means that we do not require the server to return to the origin after serving all requests.
We aim to bound the competitive ratio of the problem, i.e., the smallest ratio any online algorithm can guarantee between the completion time of its solution compared to an (offline) optimum solution that knows all requests ahead of time. To date, the best known lower bound of on this ratio was shown by Bjelde et al. [5], already for online TSP, where for all requests (i.e., requests only need to be visited). The best known upper bound of was achieved by the Smartstart algorithm [4].
Our results.
Our first result is an improved lower bound for online Dial-a-Ride on the line. Importantly, since the bound of roughly was shown to be tight for online TSP [5], our new bound is the first time that Dial-a-Ride on the line can be strictly separated from online TSP in terms of competitive analysis. In addition, our bound is the currently best known lower bound even for general metric spaces. Specifically, we show the following.
Theorem 1.1**.**
Let be the second largest root of the polynomial . There is no -competitive algorithm for open, non-preemptive () online Dial-a-Ride on the line for any .
Our construction is a non-trivial variation of the construction achieving roughly for online TSP [5]. This construction is comprised of an initial request, a first stage consisting in turn of different iterations, and a second stage. We show that, by using a proper transportation requests as initial requests, we can adapt a single iteration of the first stage as well as the second stage to achieve the bound of roughly in the Dial-a-Ride setting.
Our second result is an improved algorithm SmarterStart for online Dial-a-Ride on the line. This algorithm improves the waiting strategy of the Smartstart algorithm, which was identified as a weakness in [4]. We show that this modification improves the competitive ratio of the algorithm and give a tight analysis. Specifically, we show the following.
Theorem 1.2**.**
The competitive ratio of SmarterStart is (roughly) .
The general idea of SmarterStart is to improve the tradeoff between the case when the algorithm waits before starting its final schedule and the case when it starts the final schedule immediately. Our modification of Smartstart significantly improves the performance in the former case, while only moderately degrading the performance in the latter case. Overall, this results in an improved worst-case performance.
Related Work.
The online Dial-a-Ride problem has received considerable attention in the past (e.g. [1, 4, 5, 6, 9, 13]). Table 1 gives an overview of the currently best known bounds on the line for open online Dial-a-Ride and its special case open online TSP.
The following results are known for closed online Dial-a-Ride: For general metric spaces, the competitive ratio is exactly , both for online Dial-a-Ride as well as online TSP [1, 3, 9]. On the line, a better upper bound is known only for online TSP, where the competitive ratio is exactly [3, 5]. The best known lower bound for closed, non-preemptive Dial-a-Ride on the line is [5].
When the objective is to minimize the maximum flow time, on many metric spaces no online algorithm can be competitive [16, 17]. Hauptmeier et al. [12] showed that a competitive algorithm is possible if we restrict ourselves to instances with “reasonable” load. Yi and Tian [19] considered online Dial-a-Ride with deadlines, where the objective is to maximize the number of requests that are served in time. Other interesting variants of online Dial-a-Ride where destinations of requests are only revealed upon their collection were studied by Lipmann et al. [18] as well as Yi and Tian [20].
For an overview of results for the offline version of Dial-a-Ride on the line, see [8]. Without release times, Gilmore and Gomory [10] and Atallah and Kosaraju [2] gave a polynomial time algorithm for closed, non-preemptive Dial-a-Ride on the line with capacity . Guan [11] showed that the closed, non-preemptive problem is hard for , and Bjelde et al. [5] extended this result for any finite capacity in both the open and the closed variant. Bjelde et al. [5] also showed that the problem with release times is already hard for finite in both variants, and Krumke [14] gave a 3-approximation algorithm for the closed variant. The complexity for the case remains open. For closed, preemptive Dial-a-Ride on the line without release times, Atallah and Kosaraju [2] gave a polynomial time algorithm for and Guan [11] for . Charikar and Raghavachari [7] presented approximation algorithms for the closed case without release times on general metric spaces.
2 General Lower Bound
In this section, we prove Theorem 1.1. Let and Alg be a deterministic online algorithm for open online Dial-a-Ride. Let , be the second largest root of the polynomial . We describe a request sequence such that .
We first give a high-level description of our construction disregarding many technical details. Our construction is based on that in [5] for the TSP version of the problem. That construction consists of two stages: After an initial request (assuming w.l.o.g. Alg’s position at time is at most [math]), the first stage starts. This stage consists of a loop, which ends as soon as two so-called critical requests are established. The second stage consists of augmenting the critical requests by suitable additional ones to show the desired competitive ratio. A single iteration of the loop only yields a lower bound of roughly , but as the number of iterations approaches infinity one can show the tight bound of roughly in the limit.
In the Dial-a-Ride setting, we show a lower bound of roughly using the same general structure but only a single iteration. Our additional leeway stems from replacing the initial request with initial requests of the form where : At the time when an initial request is loaded, we show that w.l.o.g. all requests are loaded and then proceed as we did when was served. In the new situation, the algorithm has to first deliver the initial requests to be able to serve additional requests. For the optimum, the two situations however do not differ, because in the new situation there will be an additional request to the right of later anyway. Interestingly, this leeway turns out to be sufficient not only to create critical requests (w.r.t. a slightly varied notion of criticality) for a competitive ratio of larger than but even strictly larger than . The second stage has to be slightly adapted to match the new notion of criticality. It remains unclear how to use multiple iterations in our setting.
We start by making observations that will simplify the exposition. Consider a situation in which the server is fully loaded. First note that it is essentially irrelevant whether we assume that the server, without delivering any of the loaded requests, can still serve requests for which : If it can, we simply move and by apart, forbidding the server to serve it before delivering one of the loaded requests first. Therefore, we assume for simplicity that, when fully loaded, the server has to first deliver a request before it can serve any other one. We note that, in our construction, the above idea can be implemented without loss, not even in terms of .
The latter discussion also motivates restricting the space of considered algorithms: We call Alg eager if it, when fully loaded with requests with identical destinations, immediately delivers these requests without detour. It is clear that we can transform every algorithm into an eager algorithm by letting it deliver the requests right away, waiting until would have delivered them, and then letting it continue like . Since cannot collect or serve other requests while being fully loaded, we have for every request sequence .
Observation 2.1**.**
Every algorithm for online Dial-a-Ride can be turned into an eager algorithm with the same competitive ratio.
Thus, we may assume that Alg is eager. We now consider the second stage and then design a first stage to match the second stage. Suppose we have two requests and with to the right and to the left of the origin, respectively. We assume that Alg serves first at some time . Now suppose we could force Alg to serve directly after , even if additional requests are released. Then we could just release the request and we would have
[TABLE]
since Opt can serve the three requests in time by serving first. In fact, we will show that we can force Alg into this situation (or a worse situation) if the requests and satisfy the following properties. To describe the trajectory of a server, we use the notation “” for the tour that moves the server from its current position with unit speed to the point .
Definition 2.2**.**
We call the last two requests and of a request sequence with critical for Alg if the following conditions hold:
- (i)
Both tours and serve all requests presented until time . 2. (ii)
Alg serves both and after time and Alg’s position at time lies between and . 3. (iii)
If Alg serves before , it does so no earlier than . 4. (iv)
If Alg serves before , it does so no earlier than . 5. (v)
It holds that
Lemma 2.3**.**
If there is a request sequence with two critical requests for Alg, we can release additional requests such that Alg is not -competitive on the resulting instance for any .
Definition 2.2 differs from [5, Definition 5] only in property (v), which is in the original paper. Lemma 2.3 has been proved in [5, Lemma 6] for request sequences that satisfy the properties of [5, Definition 5], however, a careful inspection of the proof of [5, Lemma 6] shows that the statement of Lemma 2.3 also holds for request sequences that only satisfy (v) instead of . For a detailed proof, see Appendix A. Thus, our goal is to construct a request sequence that satisfies all properties of Definition 2.2.
The remaining part of this section focusses on establishing critical requests. There are no requests released until time . Without loss of generality, we assume that Alg’s position at time is (the other case is symmetric). Here and throughout, we let denote the position of Alg’s server at time . Now, let
[TABLE]
and let initial requests with appear. These are the only requests appearing in the entire construction with a starting point differing from the destination. We make a basic observation on how Alg has to serve these requests.222Omitted proofs can be found in the appendix.
Lemma 2.4**.**
Alg cannot collect any of the requests before time . If Alg collects the requests after time or serves requests before loading the remaining , it is not -competitive.
Proof.
Alg cannot collect any before time since its position at time is . Moreover, Alg is not -competitive if it collects one of the requests after time , since it cannot finish before time and we have
[TABLE]
Assume Alg serves requests before loading the remaining . Then, because of
[TABLE]
we have
[TABLE]
∎
We hence may assume that Alg loads all requests at the same time. Let be the time Alg loads the requests . We start the first stage and present a variant of a single iteration of the construction in [5]: We let the request appear and define the function
[TABLE]
which can be viewed as a line in the path-time diagram. Because of , we have , i.e., Alg’s position at time is to the right of the line . Thus, Alg crosses the line before it serves . Let be the time Alg crosses for the first time and let the request appear. Assume Alg crosses the line and serves before . Then it does not serve before time
[TABLE]
Now assume Alg crosses at time and serves before . Then it does not serve serve before time
[TABLE]
The following lemma shows that the two requests cannot be served before these respective times by establishing that indeed .
Lemma 2.5**.**
Alg can neither serve before time nor can it serve before time .
Proof.
Since Alg is eager, it delivers the requests without waiting or detour, i.e., we have . Furthermore, we have
[TABLE]
i.e., Alg’s position at time is to the right of . The earliest possible time Alg crosses is the solution of
[TABLE]
which is . The inequality
[TABLE]
implies that we have
[TABLE]
Because of inequality (2) Alg does not serve before and because of the inequalities (4) and (3) it does not serve before time . ∎
In fact, also the other properties of critical requests are satisfied.
Lemma 2.6**.**
The requests and of the request sequence are critical.
Proof.
We have to show that the requests and of the request sequence satisfy the properties (i) to (v) of Definition 2.2. The release time of every request is equal to its starting position, thus every request can be served/loaded immediately once its starting position is visited and (i) of Definition 2.2 is satisfied. At time Alg has not served , because for that it would have needed to go right from time [math] on; it has not served either, because during the period of time Alg and were on different sides of . This establishes the first part of (ii) of Definition 2.2. Furthermore at time Alg is at position with
[TABLE]
Therefore, the second part of (ii) of Definition 2.2 is satisfied as well.
Lemma 2.5 shows that (iii) and (iv) of Definition 2.2 are satisfied. It remains to show that property (v) is satisfied. For this we need to examine the release time of . The time is largest if Alg tries to avoid crossing the line for as long as possible, i.e., it continues to move right after serving the requests . Then, we have for and is the solution of
[TABLE]
Thus, in general, we have , i.e.,
[TABLE]
For property (v), we need . This is satisfied if
[TABLE]
which is equivalent to
[TABLE]
which is true by definition of .∎
Together with Lemma 2.3, this completes the proof of Theorem 1.1.
3 An Improved Algorithm
One of the simplest approaches for an online algorithm to solve Dial-a-Ride is the following: Always serve the set of currently unserved requests in an optimum offline schedule and ignore all new incoming request while doing so. Afterwards, repeat this procedure with all ignored unserved requests until no new requests arrive. This simple algorithm that is often called Ignore [1] has a competitive ratio of exactly [4, 14]. The main weakness of Ignore is that it always starts its schedule immediately. Ascheuer et al. showed that it is beneficial if the server waits sometimes before starting a schedule and introduced the Smartstart algorithm [1], which has a competitive ratio of roughly [4].
We define to be the smallest makespan of a schedule that starts at position at time and serves all requests in after they appeared (i.e., the schedule must respect release times). For the description of online algorithms, we denote by the current time and by the set of requests that have appeared until time but have not been served yet.
The algorithm Smartstart is given in Algorithm 1. Essentially, at time , Smartstart waits before starting an optimal schedule to serve all available requests at time
[TABLE]
where is the current position of the server and is a parameter of the algorithm that scales the waiting time. Importantly, like Ignore, Smartstart ignores incoming requests while executing a schedule.
Birx and Disser identified that Smartstart’s waiting routine defined by inequality (6) has a critical weakness [4, Lemma 4.1]. It is possible to lure the server to any position in time for every . Roughly speaking, a request is released first and then for every a request follows. The schedule to serve the request is started at time and finished at time . The schedule to serve the request at position is not started earlier than time
[TABLE]
This time is (depending on the choice of ) later than the current time for every . Thus there is no waiting time for any schedule except the first one and the server reaches position at time . We see that the request sequence to lure the server away heavily uses that inequality (6) relies on Smartstart’s current position , when computing the waiting time. Thus, we modify the waiting routine of Smartstart to avoid luring accordingly. Denote by the set of requests that have been released until time .
The improved algorithm SmarterStart is given in Algorithm 2. At time , it waits before starting an optimal schedule to serve all available requests at time
[TABLE]
Again, is a parameter of the algorithm that scales the waiting time. In contrast to Smartstart, the waiting time is dependent on the length of the optimum offline schedule serving all requests appeared until the current time and starting from the origin. This guarantees that the server cannot be forced to reach any position before time since we always have if contains a request with destination in position .
Whenever we need to distinguish the behavior of SmarterStart for different values of , we write to make the choice of explicit. The length of SmarterStart’s trajectory is denoted by . Note that the schedules used by Ignore, Smartstart and SmarterStart are NP-hard to compute for , see [5].
We let be the number of schedules needed by SmarterStart to serve . The -th schedule is denoted by , its starting time by , its starting point by , its ending point by , and the set of requests served in by . For convenience, we set .
3.1 Upper Bound for SmarterStart
We show the upper bound of Theorem 1.2. The completion time of SmarterStart is
[TABLE]
First, observe that, for all , , and , we have
[TABLE]
Similar to [4], we distinguish between two cases, depending on whether or not SmarterStart waits after finishing schedule and before starting the final schedule . If SmarterStart waits, the starting time of schedule is given by
[TABLE]
otherwise, we have
[TABLE]
We start by giving a lower bound on the starting time of a schedule. It was shown in [4] that the schedule of Smartstart is never started earlier than time . This changes slightly for SmarterStart.
Lemma 3.1**.**
Algorithm SmarterStart does not start schedule earlier than time , i.e., we have .
Proof.
Since is the ending point of schedule , there is a request with destination in in the set . All requests of appear before time , which implies that they are part of the set . Thus, we have
[TABLE]
and therefore
[TABLE]
Using Lemma 3.1, we can give an upper bound on the length of SmarterStart’s schedules, which is an essential ingredient in our upper bounds. The following lemma is proved similarly to [4, Lemma 3.2], which yields an upper bound of for the length of every schedule of Smartstart.
Lemma 3.2**.**
For every schedule of SmarterStart, we have
[TABLE]
Proof.
First, we notice that by the triangle inequality we have
[TABLE]
Now, let be the first request of that is picked up by Opt and let be its starting position and be its release time. We have
[TABLE]
again by the triangle inequality. Since Opt serves all requests of starting at position no earlier than time , we have
[TABLE]
which yields
[TABLE]
Since is the destination of a request, Opt needs to visit it. In the case that Opt visits before collecting , Opt still has to collect and serve every request of after it has visited position the first time, which directly implies
[TABLE]
On the other hand, if Opt collects before visiting the position , we have
[TABLE]
since Opt cannot collect before time and then still has to visit position . Thus, we have
[TABLE]
This implies
[TABLE]
since the minimum above is largest for . ∎
The following proposition uses Lemma 3.2 to provide an upper bound for the competitive ratio of SmarterStart, in the case that SmarterStart does have a waiting period before starting the final schedule.
Proposition 3.3**.**
In case SmarterStart waits before executing , we have
[TABLE]
Proof.
Assume SmarterStart waits before starting the final schedule. Then Lemma 3.2 yields the claimed bound:
[TABLE]
In comparison, the upper bound for the competitive ratio of Smartstart, in case Smartstart has a waiting period before starting the final schedule is [4, Proposition 3.2]. Note that SmarterStart’s bound is better than Smartstart’s bound for .
It remains to examine the case that the algorithm SmarterStart has no waiting period before starting the final schedule. For this we use two lemmas from [4] originally proved for Smartstart, which are still valid for SmarterStart since they give bounds on the optimum offline schedules independently of the waiting routine.
By we denote the leftmost position and by the rightmost position that needs to be visited by the server. We denote by the leftmost and by the rightmost position that occurs in the requests . Note that and need not lie on different sides of the origin, in contrast to .
Lemma 3.4** (Lemma 3.4, Full Version of [4]).**
Let with be a schedule of SmarterStart. Moreover, let for some . Then, we have
[TABLE]
Lemma 3.5** (Lemma 3.6, Full Version of [4]).**
Let with be a schedule of SmarterStart. Moreover, let and for some . Then, for every point that is visited by we have
[TABLE]
Using the bounds established by Lemma 3.4 and Lemma 3.5, we can give an upper bound for the competitive ratio of SmarterStart if the server is not waiting before starting the final schedule.
Proposition 3.6**.**
If SmarterStart does not wait before executing , we have
[TABLE]
Proof.
Assume algorithm SmarterStart does not have a waiting period before the last schedule, i.e., SmarterStart starts the final schedule immediately after finishing . Without loss of generality, we assume throughout the entire proof by symmetry.
First of all, we notice that we may assume that SmarterStart executes at least two schedules in this case. Otherwise either the only schedule has length [math], which would imply , or the only schedule would have a positive length, implying a waiting period. Let be the first request of that is served by Opt and let be its starting point and be its release time. We have
[TABLE]
Since Opt serves all requests of after time , starting with a request with starting point , we also have
[TABLE]
Furthermore, we have
[TABLE]
since otherwise would hold. This gives us
[TABLE]
We have
[TABLE]
because Opt has to visit both and after time : It has to visit to collect and it has to visit to deliver some request of . Using the above inequalitiy, we get
[TABLE]
In the case , we have
[TABLE]
Thus, we may assume . Similarly as in inequality (28), we get
[TABLE]
where the last inequality follows, because there exists a request in with release date later than . This means the claim is shown if we have
[TABLE]
since then we have
[TABLE]
Therefore, we may assume in the following that
[TABLE]
Let for some . By definition of and we have
[TABLE]
In the case that Opt visits position before it collects , we have
[TABLE]
Similarly, if Opt collects before it visits position for the first time, we have
[TABLE]
Thus, inequality (33) holds in general. To sum it up, we may assume that
[TABLE]
holds. In the following, denote by the leftmost starting or ending point and by the rightmost starting or ending point of the requests in . We compute
[TABLE]
Obviously, position is visited by SmarterStart in schedule . Therefore, is smaller than or equal to the rightmost point that is visited by SmarterStart during schedule , which gives us
[TABLE]
On the other hand, because of , we have , which implies . By definition of and , we have . This gives us and
[TABLE]
To sum it up, we have
[TABLE]
The inequality above gives us
[TABLE]
In comparison, the upper bound for the competitive ratio of Smartstart in case it does not have a waiting period before starting the final schedule is [4, Proposition 3.4]. Note that SmarterStart’s bound is slightly worse than Smartstart’s bound for . However, in combination with the bound of Proposition 3.3, SmarterStart has a better worst-case than Smartstart.
Theorem 3.7**.**
Let be the largest solution of , i.e.,
[TABLE]
Then, is -competitive with .
Proof.
For the case, where SmarterStart does wait before starting the final schedule, we have established the upper bound
[TABLE]
in Proposition 3.3 and for the case, where SmarterStart starts the final schedule immediately after the second to final one, we have established the upper bound
[TABLE]
in Proposition 3.6. Therefore, if it exists,
[TABLE]
is the parameter for SmarterStart with the smallest upper bound. We note that is strictly decreasing for and that is strictly increasing for . Therefore, if an intersection point of and that is larger than exists, then this is at . Indeed, the intersection point exists, which is the largest solution of
[TABLE]
The resulting upper bound for the competitive ratio is
[TABLE]
3.2 Lower Bound for SmarterStart
We show the lower bound of Theorem 1.2. In this section, we explicitly construct instances that demonstrate that the upper bounds given in the previous section are tight for certain ranges of , in particular for (as in Theorem 3.7). Further, we show that choices of different from yield competitive ratios worse than . Together, this implies that is exactly the best possible competitive ratio for SmarterStart.
Proposition 3.8**.**
Let . For every sufficiently small , there is a set of requests such that SmarterStart waits before starting the final schedule and such that the inequality
[TABLE]
holds, i.e., the upper bound established in Proposition 3.3 is tight for .
Proof.
Let with and . Let the request
[TABLE]
appear. For all we have . Thus, SmarterStart starts its first schedule at time and reaches position at time . Next, we let the second and final request
[TABLE]
appear. For we have
[TABLE]
Thus, the second and final schedule is not started before time
[TABLE]
By assumption, we have and , i.e., , which implies that for the time , when SmarterStart reaches position , the inequality
[TABLE]
holds. (Note that inequality (39) also holds for slightly larger if we let .) Because of inequality (39), SmarterStart has a waiting period and starts the schedule at time
[TABLE]
Serving from position takes time
[TABLE]
To sum it up, we have
[TABLE]
On the other hand, Opt goes from the origin to to collect at time (i.e., it has to wait for units of time after it reaches position ). Then Opt goes straight to position delivering and serving . Therefore, we have
[TABLE]
Note, that Opt can do this even if the capacity is , since does not need to be carried over position , where appears. Since we have , we obtain
[TABLE]
as claimed. ∎
Proposition 3.9**.**
Let . For every sufficiently small there is a set of requests such that SmarterStart immediately starts after and such that
[TABLE]
i.e., the upper bound established in Proposition 3.6 is tight for .
Proof.
Let with (note that for ) and . Let the request
[TABLE]
appear. For all , we have . Thus, SmarterStart starts its first schedule at time and reaches position at time . Next we let two new requests
[TABLE]
appear. For we have
[TABLE]
Thus, the second schedule is not started before time
[TABLE]
By assumption, we have a nd , i.e., , which implies that for the time , when SmarterStart reaches position , the inequality
[TABLE]
holds. (Note that inequality (40) also holds for slightly larger if we let .) Because of inequality (40), SmarterStart has a waiting period and starts the schedule at time
[TABLE]
If SmarterStart serves before serving the time it needs is at least
[TABLE]
The best schedule that serves after serving needs time
[TABLE]
Thus, SmarterStart serves after serving and finishes at position at time
[TABLE]
Now let the final request
[TABLE]
appear. By assumption, we have , which implies
[TABLE]
i.e., the position of the request lies to the right of . Thus we have for all the equation
[TABLE]
Therefore the final schedule is not started before time
[TABLE]
However, by assumption, we have and , i.e., , which implies
[TABLE]
i.e., the starting time of the schedule is the ending time of the schedule and we have
[TABLE]
The schedule needs time
[TABLE]
To sum it up, we have
[TABLE]
On the other hand, Opt goes from the origin straight to position serving request at time (i.e., it has to wait for units of time after it reaches position ). Then Opt walks straight from the origin to position serving all remaining requests. Thus, we have
[TABLE]
Note that Opt can do this even if since for all requests the starting point is equal to the ending point. Since we have , we finally obtain
[TABLE]
as claimed. ∎
Recall that the optimal parameter established in Theorem 3.7 is the only positive, real solution of the equation
[TABLE]
which is . Therefore, according to Proposition 3.8 and Proposition 3.9 the parameter lies in the range where the upper bounds of Propositions 3.3 and 3.6 are both tight. It remains to make sure that for all that lie outside of this range the competitive ratio of is larger than . Let with (note that for ) and . Consider the set of requests with
[TABLE]
We compute SmarterStart’s completion time for the set of requests in the case and in the case .
Lemma 3.10**.**
Let the capacity of the server be arbitrary but fixed and let . We have
[TABLE]
In particular, we have
[TABLE]
for and sufficiently small .
Proof.
For all , we have . Thus, SmarterStart starts its first schedule at time and reaches position at time . We have , i.e., , which implies
[TABLE]
for , i.e. the starting position of is between [math] and . For we have
[TABLE]
Thus, the second schedule is not started before time
[TABLE]
By assumption, we have , which implies that for the time , when SmarterStart reaches position , the inequality
[TABLE]
holds. Thus, SmarterStart has a waiting period and starts the schedule at time
[TABLE]
If SmarterStart serves before serving the time it needs is at least
[TABLE]
The best schedule that serves after serving needs time
[TABLE]
Thus, SmarterStart serves after serving and finishes at position at time
[TABLE]
We have for all the equation
[TABLE]
Therefore the final schedule is not started before time
[TABLE]
which is equal to and thus smaller than . Therefore, the starting time of the schedule is the ending time of the schedule and we have
[TABLE]
The schedule needs time
[TABLE]
To sum it up, we have
[TABLE]
On the other hand, Opt goes from the origin straight to position serving request at time (i.e., it has to wait for units of time after it reaches position ). Then Opt walks straight to position collecting the request . Note that the release time of is the same as of and thus Opt has no waiting time at position . Opt reaches position and delivers at time . By assumption we have and , i.e., , which implies
[TABLE]
Thus, Opt has no waiting time at position and can serve the requests and at arrival. To sum it up, we have
[TABLE]
Note that Opt can do this even if since is the only transportation request and no other request lies between its starting position and destination. Since we have , we finally obtain
[TABLE]
The function is monotonically decreasing on . Therefore, we have
[TABLE]
for all and for sufficiently small . ∎
Lemma 3.11**.**
Let the capacity of the server be arbitrary but fixed and let . We have
[TABLE]
In particular, we have
[TABLE]
for and sufficiently small .
Proof.
For all , we have . Thus, SmarterStart starts its first schedule at time and reaches position at time . We have , i.e., , which implies
[TABLE]
for , i.e. the starting position of is between [math] and . For we have
[TABLE]
Thus, the second schedule is not started before time
[TABLE]
By assumption, we have , which implies that for the time , when SmarterStart reaches position , the inequality
[TABLE]
holds. Thus, SmarterStart has no waiting period and the starting time of the schedule is the ending time of the schedule . We have
[TABLE]
If SmarterStart serves before serving the time it needs is at least
[TABLE]
The best schedule that serves after serving needs time
[TABLE]
Thus, SmarterStart serves after serving and finishes at position at time
[TABLE]
We have for all the equation
[TABLE]
Therefore the final schedule is not started before time
[TABLE]
which is, as before, smaller than and thus smaller than . Therefore, the starting time of the schedule is the ending time of the schedule and we have
[TABLE]
The schedule needs time
[TABLE]
To sum it up, we have
[TABLE]
On the other hand, Opt goes from the origin straight to position serving request at time (i.e., it has to wait for units of time after it reaches position ). Then Opt walks straight to position collecting the request . Note that the release time of is the same as of and thus Opt has no waiting time at position . Opt reaches position and delivers at time . By assumption we have and , i.e., , which implies
[TABLE]
Thus, Opt has no waiting time at position and can serve the requests and at arrival. To sum it up, we have
[TABLE]
Note that Opt can do this even if since is the only transportation request and no other request lies between its starting position and destination. Since we have , we finally obtain
[TABLE]
The function is monotonically increasing on . Therefore, we have
[TABLE]
for all and for sufficiently small . ∎
Lemma 3.12**.**
Let . There is a set of requests such that
[TABLE]
Proof.
This is immediate consequence of Lemma 3.10 and Lemma 3.11. ∎
Figure 1 shows the upper and lower bounds that we have established. Theorem 1.2 now follows from Theorem 3.7 combined with Propositions 3.8 and 3.9, as well as Lemma 3.12.
Proof of 1.2.
We have shown in Proposition 3.8 that the upper bound
[TABLE]
established in Proposition 3.3 for the case, where SmarterStart waits before starting the final schedule, is tight for all . Furthermore, we have shown in Proposition 3.9 that the upper bound
[TABLE]
established in Proposition 3.6 for the case, where SmarterStart does not wait before starting the final schedule, is tight for all . Since lies in those ranges, the competitive ratio of is indeed exactly .
It remains to show that for every with the competitive ratio is larger. First, according to Lemma 3.12, the competitive ratio of SmarterStart with parameter is larger than . By monotonicity of , every function value in is larger than . Thus, the competitive ratio of SmarterStart with parameter is larger than , since is tight on by Proposition 3.8. Similarly, by monotonicity of , every function value in is larger than . Thus, the competitive ratio of SmarterStart with parameter is larger than , since is tight on by Proposition 3.9. ∎
Appendix A Proof of Lemma 2.3
In this section we prove Lemma 2.3. The proof is almost identical to the proof of [5, Lemma 6]. Since there are however several parts where inequalities change slightly, we decided to present the full proof here. See 2.3
Let the requests and be critical. Furthermore, let be the starting position of the request that is served first by Alg and let be the starting position of the request that is not served first by Alg. By properties (iii) and (iv) of Definition 2.2, Alg cannot serve before time . Thus, we have
[TABLE]
We have equality in inequality (41) if Alg serves the earliest possible time and then moves directly to position . However, in general Alg does not need to do this and instead can wait. At time , we have
[TABLE]
if Alg still has to serve and
[TABLE]
if is served and only is left to be served. We want to measure the delay of Alg at a time , i.e. the difference between the time Alg needs at least to serve both requests and and the time . We define for the function
[TABLE]
We make the following observation about delay.
Observation A.1**.**
Let be a time at which is not served yet. The earliest time Alg can serve is .
Lemma A.2**.**
There is a with
[TABLE]
Proof.
Because of property (ii) of Definition 2.2, at time neither nor has been served by Alg yet. Since Alg serves after , the request is not served before time
[TABLE]
i.e, is defined. Because of properties (iii) and (iv) of Definition 2.2, is not served before time . Thus, for , we have . We have
[TABLE]
i.e. . If , we have and are done. Otherwise, by inequality (42), we have . Note that Alg needs to serve at some point to be -competitive. Let be chosen such that Alg serves at time +. Therefore
[TABLE]
is defined for some sufficiently small . Define the function
[TABLE]
Note that is continuous and we have . If
[TABLE]
we have and we find in the interval . Otherwise, we have
[TABLE]
By A.1 Alg has not served at time
[TABLE]
This is a contradiction to the fact, that was chosen such that Alg serves at time +. ∎
Lemma A.3**.**
Let with
[TABLE]
Alg serves no later than time .
Proof.
Assume we have
[TABLE]
Then, by definition of and A.1, Alg can serve at time
[TABLE]
Because of inequality (43), this can only be the case if Alg serves no later than time
[TABLE]
Thus, it remains to show inequality (43). Because of property (i) of Definition 2.2 all requests can be served the tours and . By inequality 44, we have . Thus, if we have
[TABLE]
Alg is not -competitive. Therefore, we may assume
[TABLE]
and thus
[TABLE]
Inequality (43) now is equivalent to the inequality
[TABLE]
if we solve inequality (43) for . ∎
Now we have all ingredients to proof Lemma 2.3.
Proof of Lemma 2.3.
Let with
[TABLE]
We present the request
[TABLE]
and distinguish two cases.
*Case 1: *At time , Alg is at least as close to as to or it serves before .
In this case, we do not present additional requests. By Lemma A.3, Alg has served at time or before and by A.1 it does not serve earlier than time . Thus, we have
[TABLE]
*Case 2: *At time , Alg is closer to than to and it serves first.
We assume that the offline server continues moving away from the origin after serving at time . Then, the position of the offline serve at time is . We denote by
[TABLE]
the midpoint between the current position of the offline server and the position . Note that the time , when the midpoint is at position is given by
[TABLE]
We again distinguish two cases
Case 2.1: Alg does not serve until time .
In this case, we do not present additional requests. Since we are in Case 2, neither nor is served at time . Thus, we have
[TABLE]
Case 2.2: Alg serves before time .
By definition of , the delay function is defined for time , hence Alg has not served before time . Since Alg is to the right of the midpoint at time , there is a first time at which . We present the request
[TABLE]
Note that Alg is at the midpoint between and and thus, both tours and incur identical costs for Alg. We have
[TABLE]
We have , i.e., if we want to show
[TABLE]
Inequality (46) is equivalent to
[TABLE]
Since , the coefficient of is positive. Thus we may assume is minimal to show the inequality (47). By assumption, is already served at time . Hence, is minimum if, starting at time at position , Alg serves and then moves towards the origin. Then, is the solution of the equation
[TABLE]
Because of Lemma A.3, the request is already served at time . Furthermore, since the position of has not been visited yet at time , we have , i.e.,
[TABLE]
and thus, because of , we get
[TABLE]
Solving equation (49) for gives
[TABLE]
Thus, we have
[TABLE]
Using inequality (51) and plugging inequality (50) into inequality (48) gives us
[TABLE]
Note that we also used . Multiplying equality (52) with gives us
[TABLE]
By substituting (53) into (47) and noting that it is hardest to satisfy, when , we get
[TABLE]
which is true due to Definition 2.2 (v). ∎
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] Norbert Ascheuer, Sven Oliver Krumke, and Jörg Rambau. Online dial-a-ride problems: Minimizing the completion time. In Proceedings of the 17th Annual Symposium on Theoretical Aspects of Computer Science (STACS) , pages 639–650, 2000.
- 2[2] Mikhail J. Atallah and S. Rao Kosaraju. Efficient solutions to some transportation problems with applications to minimizing robot arm travel. SIAM Journal on Computing , 17(5), 1988.
- 3[3] G. Ausiello, E. Feuerstein, S. Leonardi, L. Stougie, and M. Talamo. Algorithms for the on-line travelling salesman. Algorithmica , 29(4):560–581, 2001.
- 4[4] A. Birx and Y. Disser. Tight analysis of the smartstart algorithm for online dial-a-ride on the line. In Proceedings of the 36th International Symposium on Theoretical Aspects of Computer Science (STACS) , 2019. Full version: https://arxiv.org/abs/1901.04272.
- 5[5] Antje Bjelde, Yann Disser, Jan Hackfeld, Christoph Hansknecht, Maarten Lipmann, Julie Meißner, Kevin Schewior, Miriam Schlöter, and Leen Stougie. Tight bounds for online TSP on the line. In Proceedings of the 28th Annual Symposium on Discrete Algorithms (SODA) , pages 994–1005, 2017.
- 6[6] Michiel Blom, Sven O. Krumke, Willem E. de Paepe, and Leen Stougie. The online TSP against fair adversaries. INFORMS Journal on Computing , 13(2):138–148, 2001.
- 7[7] Moses Charikar and Balaji Raghavachari. The finite capacity dial-a-ride problem. In Proceedings of the 39th Annual Symposium on Foundations of Computer Science (FOCS) , pages 458–467, 1998.
- 8[8] Willem E. de Paepe, Jan Karel Lenstra, Jiri Sgall, René A. Sitters, and Leen Stougie. Computer-aided complexity classification of dial-a-ride problems. INFORMS Journal on Computing , 16(2):120–132, 2004.
