# Computing Idle Times in Fuzzy Flexible Job Shop Scheduling
## 4 Results  
The objective of the experimental study is to empirically assess the three different approaches introduced in Section 3 in order to compute the total core idle time for fuzzy schedules. We will use 12 benchmark instances from the literature [25]: 07a, 08a, 09a, 10a, 11a, and 12a with 15 jobs, 8 resources, and 293 operations (denoted as \(15\times 8\times 293\) in the following) and 13a, 14a, 15a, 16a, 17a, and 18a of size \(20\times 10\times 387\). In instances 07a, 08a, 09a, 13a, 14a, and 15a, operations have the same processing time, regardless of the resources where they are executed, while instances 10a, 11a, 12a, 16a, 17a, and 18a have resource-dependent processing times. There are also three increasing flexibility levels, with 07a, 10a, 13a, and 16a being those instances with the lowest flexibility and 09a, 12a, 15a and 18a being those instances with the highest flexibility.  
The study follows the methodology proposed in [26]. For each instance, schedules will be generated and compared in terms of their performance regarding \(\widehat{\text{TCIT}}\) using first the measures introduced in Section 2.3.1 and then those introduced in Section 2.3.2. In both cases, this will be done with two types of experiments: over random solutions and with solutions obtained with a search algorithm. The goal of the random-solution experiments is to evaluate the three alternatives for computing \(\widehat{\text{TCIT}}\) without the possible bias that may be introduced via any solver, whereas the searched-solution experiments pretend to compare the three models when embedded in a search algorithm, with the objective of evaluating their capability of guiding the search towards good schedules. In both sets of experiments, 100 schedules are obtained per instance; notice that, for the searched-solution comparisons, this means generating 100 schedules for each of the three models \((\widehat{\text{TCIT}}^{N},\widehat{\text{TCIT}}^{K},\) and \(\widehat{\text{TCIT}}^{C})\) under consideration.  
As a solution method for the searched-solution comparisons, we employ the tabu search algorithm proposed in [51] for the classical job shop, extending the neighbourhood function so that every operation is moved to all feasible positions both in its current resource and in others where it can be executed. This is probably the most naive neighbourhood available, as it tries to reschedule every operation in every position, but at the same time, it ensures connectivity and is agnostic to the models, minimising their influence on the results. At every iteration, a tabu search generates all possible neighbours and selects the best one that is not tabu. Then, it stores the inverse of the move performed to obtain the selected neighbour in a memory structure, called the tabu list, so, in the next iterations, that move is forbidden, thus avoiding the undoing of recently made moves. In this way, the tabu search is able to escape local optima. In addition, the tabu list also serves as a diversification mechanism, as different movements are encouraged. A detailed pseudocode can be found in Figure 11. The tabu search parameters are set to the values used in [26] for the same set of instances. This algorithm will be used in all experiments, with the only change being the objective function, which will vary in order to test the different proposals.