Preprocessing Bids and Allocations

The previous section has considered the allocation problem; that is, to determine the allocation that maximises the expected utility. However, in order to construct the objective function in equation 6.12 we must first generate for each valuationvi(τ)its expected valuations considering

the task allocations inKvi(τ). In this section we offer a dynamic programming approach to this

problem since, as detailed below, the problem observes the principle of optimality (in the sense proposed in [Skiena, 1998]). Thus, partial solutions can be optimally extended with regard to the state after the partial solution, instead of to the partial solution itself. In our particular case, the local task allocations forvi(τ)can be obtained from the allocations assessed for sets of tasks τ′_⊆τ.

To this end, algorithms 1 and 2 formalise our DP approach. Specifically, algorithm 1 calculates the expected valuations for each askvi(τ)based on the potential task allocations for the tasks in τusing the costs inc. Task allocations are stored in tableA, which is employed by the algorithm as a look-up table indexed by task vectors, whereas expected valuations are stored inE. Notice that the first step in the algorithm (line 1) refers to the following preprocessing actions:

PRE1: Remove non-competitive bids. Notice that we regard a bid over a set of tasksτ as non- competitive if all the valuations for tasks inτ are lower than the bid. Formally, we removecj(τ)

ifmax(v(τ))< cj(τ′),τ′ ⊆τ.

PRE2: Remove bids that cause free disposal. At this stage, we prune those bids containing tasks

for which no valuations exist. Formally, we removecj(τ)if∃τ ∈τ such that∄vi(τ′)andτ ∈ τ′.

Having carried out these two preprocessing actions, table A is then filled in by the recursive function allocation outlined by algorithm 2. This algorithm differentiates two cases when as- sessing task allocations, depending on whether the taskτ received as an input is single (lines 2 to 4) or combinatorial (lines 5 to 8). For the single task case, the algorithm locates all bids in

cthat contain the task (line 3). For combinatorial tasks, the algorithm generates two recursive calls: one for all the elements in the task vector but the last one (line 6), and another for the last element in the task vector (line 7). At this point the algorithm looks for stored results in

A to avoid revisiting the same subproblem. If such stored results do exist, they are retrieved, otherwise the recursive calls proceed. Finally, the task allocations obtained in lines 6 and 7 are combined to provide all possible task allocations (line 8). Notice, therefore, that algorithm 2 is in fact a memoized [Cormen et al., 1990] recursive algorithm: it maintains a table, A, with subproblem solutions, but the control structure for filling in the table is recursive. A memoized algorithm is desirable in this context because it only solves those subproblems that are definitely required. For instance, consider a call to allocation with combinatorial taskτ =_hτ1, τ2, τ3ias

input. Such a call is split into two recursive calls with inputs_hτ1, τ2iandhτ3i.

In order to combine task allocations, in algorithm 2 we use the⊗operator over sets of task allo- cations (line 8) that we define as follows:∆_⊗∆′_={(δ

i, δj)|δi∈∆, δj ∈∆′and∄(τ, ck(τ))∈ δi(τ′, cl(τ′))∈δjsuch thatck(τ)andcl(τ′)are mutually exclusive. Notice that the⊗operator

is defined as a variation of the Cartesian product that discards task allocations containing XOR bids. Thus, the⊗operator implements the following pruning actions:

PRE3: Discard task allocations containing mutually exclusive bids.

After assessing a given task allocation, algorithm 2 returns the result (line 12) to algorithm 1 so that it is stored in the look-up table (line 5). After that, algorithm 1 carries out the following further preprocessing actions.

PRE4: Remove task allocations that cause free disposal. Eventually some sets of tasks (along

with their subtasks) may only be asked for by a single agent. In such a case, there is no sense in considering local task allocations with overlapping bids (bids over some common task(s)) because their acceptance would only be possible if we allowed free disposal (line 7).

PRE5: Remove non-competitive task allocations. We regard a local task allocation as non-

competitive if the total cost of the bids composing the allocation is higher than the expected valuation for the tasks being considered. For each allocation, the expected value is computed using equation 6.11 and stored (line 9) if this value is greater or equal to the cost.

Algorithm 1 function task allocations (V,E,C,t) 1: C′←PRE2(PRE1(V, C)); 2: fori∈ {1, . . . , I}do 3: forvi(τ, θ)∈vido 4: ifA[τ] =_∅then 5: A[τ]←allocation(τ, A, C′); 6: end if 7: K_v i(τ)←PRE4(A[τ]); 8: forA ∈ Kvi(τ)do 9: E[v_i(τ),_K]_←PRE5(vi(τ),K,t); 10: end for 11: end for 12: end for 13: returnE

Algorithm 2 function allocation (τ,A,C)

1: ifA[τ] =_∅then 2: caseτ =_hτii: 3: α ← {(τi, ck(τ′))|τi ∈τ′,1≤k≤I,τ′∈2T}; 4: break; 5: caseτ =_hτi1, . . . , τim+1i: 6: ∆m ←allocation(hτi1, . . . , τimi, A, C); 7: ∆m+1 ←allocation(hτ_im+1i, A, C); 8: α ←∆m⊗∆m+1; 9: else 10: α←A[τ] 11: end if 12: returnα

Algorithm 1 runs in timeO(n_·mr)in the worst case, wheremstands for the total number of bids, r stands for the number of tasks, andn stands for the total number of valuations. The worst case occurs when all valuations and bids are combinatorial and over all tasks8. Otherwise, the running time of the algorithm is highly dependent on the sparsity of bids and valuations. Thus, the lower the degree of (task) overlapping of bids and valuations, the lower the running time9. Besides, the pruning actions included in the algorithm are expected to further reduce the search space, and thus the running time. The results of algorithm 1 are used for building the optimisation model in section 6.8.1, which is solved using ILOG’s CPLEX.

Notice that a brute-force approach to our optimisation problem would be extremely expensive. In this case, the number of feasible allocations for a given valuation would amount to m₁r. Thereafter, considering a different valuation combined with the former one, would lead us to consider m−₁1r feasible allocations to be combined with the feasible allocations obtained so far (and thus m₁r· m₁−1roverall). In the general case, when jointly consideringnvaluations,

8_{This case can be generated in CATS [Leyton-Brown et al., 2000] with the normal distributions with the para-}

meters of their testbed set as follows,µgoodsto high andσgoodsto low.

9

the total number of feasible allocations would amount toQn_i=0(m−i)r. This expression asymp- totically converges to(m!)rifn≃mandmrnifn≪m(which is much larger than then·mr

of our algorithm). Notice that a brute-force approach to our optimisation problem would be extremely expensive. In this case, the number of feasible allocations for a given valuation would amount to m₁r. Thereafter, considering a different valuation combined with the former one, would lead us to consider m₁−1r feasible allocations to be combined with the feasible alloca- tions obtained so far (and thus m₁r· m₁−1roverall). In the general case, when jointly consid- eringnvaluations, the total number of feasible allocations would amount toQn_i=0(m₋i)r_{. This}

expression asymptotically converges to(m!)rifn_≃mandmrnifn_≪ m. Thus, very simple problems, for instance withm=10,r=5 andn= 10, cannot be solved using a high performance optimiser such as CPLEX as brute-force would explore a search space of cardinality(10!)5_{. On}

the other hand algorithm 1 would generate10_·105 possible allocations, feeding a branch and cut algorithm. Hoffman and Padberg [1993] report the possibility of solving an instance of a very similar problem in under 25 minutes.

Having thus shown how to reduce the computational load whilst implementing TBM, we next experimentally compare its performance against the mechanism developed in [Porter et al., 2002].