![](bg7.png)
Table 1: Results of solving the Continuous SSPD.
(Nodes, Algor. CPU Best PR Perc-
Arcs) time (s) Val. (%) entage
(23,40) N=1 0.36 216 18.06 0%
(23,40) N=10 0.42 205 13.66 0%
(23,40) N=100 0.40 205 13.66 0%
(23,40) Matlab 1.50 177 - -
(50,167) N=1 2.72 13135 17.88 0%
(50,167) N=10 2.72 13302 18.91 0%
(50,167) N=100 2.78 13155 18.01 0%
(50,167) Matlab 47.54 10786 - -
(75,215) N=1 6.62 14461 17.76 30%
(75,215) N=10 6.42 14363 17.20 20%
(75,215) N=100 6.52 13446 11.55 40%
(75,215) Matlab 156.60 11893 - -
(100,351) N=1 30.08 7464 -36.90 70%
(100,351) N=10 30.02 7471 -36.77 70%
(100,351) N=100 30.34 7488 -36.46 70%
(100,351) Matlab 133.26 10218 - -
(100,573) N=1 129.02 13241 10.90 50%
(100,573) N=10 138.72 10847 -8.77 83%
(100,573) N=100 140.26 10021 -17.73 100%
(100,573) Matlab 200.70 11798 - -
CPU time. Moreover, the CPU time of our algorithm
does not exceed 70% of the CPU time Matlab takes.
With respect to the produced solutions, for the two
large graphs (n = 100), the Stochastic Projected Gra-
dient algorithm finds the best solutions, while Matlab
performs better on the small graphs with n <= 75.
Moreover, with N = 100 samples our algorithm pro-
duces better solutions than Matlab in 81% of the runs
on the graphs with 100 vertices. To resume, for the
instances above, the Stochastic Projected Gradient al-
gorithm performs better than Matlab’s optimization
toolbox when graph sizes are large, both in terms
of CPU time and produced solutions. For the small
graphs, Matlab gives better solutions but takes 3 times
more CPU time than the Stochastic Projected Gradi-
ent algorithm.
Regarding the number of samples N, we observe
no big difference between taking 10 samples and 100.
However, in general, taking 100 samples gives better
results than taking 1 sample: for instances 1, 3 and
5, better solutions are found with 100 samples, while
the results are comparable for the other two instances.
Notice that the number of samples N has no signif-
icant influence on the CPU time, although the com-
putation load is clearly heavier at each iteration with
N = 100 than with N = 1. However, recall that the
stopping criterion is not a fixed number of iterations
but merely based on a measure of convergence. This
explains, that on some instances the algorithm takes
less time when considering 100 samples per iteration
than when considering only one.
5.2 The Combinatorial SSPD
In this section, we present our numerical results of the
above mentioned branch-and-bound algorithm. For
the five networks, we run two cases: in the first
one, the expectation and the variance of the delay
are directly proportional to the cost of the arc (in-
stances SSPD1a - SSPD5a); in the second one, they
are not proportional to the cost (instances SSPD1b -
SSPD5b). For the first case, by Theorem 1 in section
3, we get the conclusion that the optimal solution of
SSPD can be obtained in polynomial time by solving
a classic shortest path problem. This provides us with
a benchmark for the solution given by our algorithm.
However, this doesn’t suit to the second case.
Based on the numerical results for the continu-
ous relaxation of SSPD, we set the sample number
N to 10 for both cases. The other parameters are
generated as follows: for the first case, the penalty
d (the delay penalty per time unit) is 10, the expec-
tation and the variance of the delay for each arc a
are µ(a) = 10∗c(a) and σ
2
(a) = µ(a)/9, respectively,
and the delay threshold D is set to the mean of the de-
lay of the shortest path. For the second case, we use
the same instances as the continuous SSPD, i.e., the
parameters are the same as the parameters in the con-
tinuous one. In our numerical tests, we run each in-
stance ten times. The results are shown in Table 2 and
Table 3, respectively. For each of the 10 instances,
Table 2 gives the mean of the solution value obtained
with the branch-and-bound algorithm, the benchmark
(the optimal value), the average number of considered
nodes, i.e., the number of times a lower bound is cal-
culated during the algorithm, the average CPU time
in seconds and the gap, i.e., the relative difference be-
tween the solution value of the best solution provided
by our algorithm and the benchmark; while Table 3
gives the mean of the solution value obtained with the
branch-and-bound algorithm, the average number of
considered nodes, the average CPU time in seconds.
From Table 2 and Table 3, we observe that for the
first four instances the CPU time of our branch-and-
bound algorithm does not exceed 400 seconds. Given
the NP-hardnessof the problem, the size of the graphs
ICORES 2012 - 1st International Conference on Operations Research and Enterprise Systems
262