## 5 Computational Experiments
### Results  
As Table 8 shows, the option for intermodal trips benefits the RP system since the number of not served requests (**Not Served**) reduces from \(\sim\)67% in test 1 to \(\sim\)15% and \(\sim\)11% in tests 2 and 3, respectively. Another aspect, as shown in column **Left at stop**, is the number of clients that have not completed a trip with a last leg of ride pooling, which may be of the PT+RP or three-leg trips type that are dispatched; none is left at a stop. Tables 9-11 provide average travel trip times, distances and fares. In all tables, column \"**RP trips**\" refers to trips with RP only, \"**PT trips**\" refers to trips with PT only, \"**RP + PT trips**\" refers to trips with two legs starting by RP and later transferring to PT, \"**PT + RP trips**\" refers to trips with two legs starting by PT and later transferring to RP, and those with three legs appear under \"**3-Leg trips**\". In the rows, \"**Direct**\" refers to the individual trip with exclusive RP (used as a reference for comparison with the one dispatched), \"**Expected**\" refers to the trip initially reported by the system (the dispatched one), and \"**Actual**\" refers to the experienced one at the end of the simulation after all future detours. From these intermodality options, a two-leg trip including public transport shows the best indicators. Since RP-only trips face directly urban congestion in the centre, they have a larger travel \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline \multirow{2}{*}{**Batch Size**} & \multirow{2}{*}{**\#Req.**} & \multirow{2}{*}{**Freq.**} & \multicolumn{2}{c}{**Total**} & **Step 1** & **Step 2** & **Step 3** & **Total** \\  & & & **Batch Time** & **Time** & **Time** & **Time** & **Time** \\ \hline
**1** & 2.03 & 2.15 s & 1.28 s & 0.54 s & 0.73 s & 0.01 s & 144.01 min \\
**10** & 10.49 & 11.03 s & 4.59 s & 1.02 s & 2.56 s & 1.02 s & 99.30 min \\
**30** & 26.61 & 27.95 s & 13.38 s & 1.98 s & 3.40 s & 8.14 s & 114.40 min \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Sensibility analysis on batch size. Average CPU running times distribution per batch. time (**Total**) and higher costs for the user, (**Fare**). In contrast with this, any other type of trip presents a fare remarkably cheaper than any other with a reduced travel time precisely because they skip the congestion in the centre. When compared to an RP-only trip, a trip with three legs, although with larger travel time, covers a much larger distance for a lower cost. In addition, any two-leg trips can reduce a longer trip by half the cost. In all cases, the waiting time in transfers (**wait**) and the walking time to the user's destination (**walk**) in two- or three-leg trips appear reasonably small, incentivising commuters in surrounding cities to possibly become new users of the RP system. Tables 12 and 13 show how fast the system responds to users. The first one reports the average delay times for all requests, and the second reports the average delay times for the subset of trips dispatched with a last leg (PT+RP and 3-leg trips) distinguished if a vehicle reservation has been made. The system manages to provide a tour plan on average in 6 s, with a last leg eventually dispatched between 11 and 23 min later. On the other hand, if the request cannot be served, the system rejects them on average between 12 s (Here and Now requests) to 1.7 min (Booking requests). This difference comes from the fact that an HN request is performed immediately and there is very little margin to serve it. On the other hand, B requests, even if placed 30 min in advance, are considered unserviceable if they remain in the system for an extended length of time.