Evolución y definiciones del concepto logística inversa

Given the variance in hill climb’s execution time, we implemented our Hill Climbing algorithm to be configurable in its minimum and maximum runtime. We accomplished this flexibility by allowing the number of random restarts and sideways moves to be configurable, where the minimum and maximum number of rankings evaluated could be hard-coded, so that evaluation time could be capped if needed. As discussed in Section 3.4.3, we decided to expand the evaluation portion to contain the n+2 neighboring node in order to potentially improve search results. We found that the runtime was low enough that examining the n+2 neighboring nodes would not increase computation time greatly, but would allow for consideration of additional swaps that could result in better rankings.

The basic implementation of the Hill Climbing algorithm for the Minimum Feedback Arc Set in our program followed the original design outlined in Section 3.4.3. The algorithm first created a preordering of teams based upon their net edge weights in the input graph. Then, a series of temporary swaps were performed upon this preordering, and the resulting ranking with the best swap with the lowest total backedge weight was saved. This continued until no further improvement in total backedge weight is seen. Sideways moves, as outlined in Section 3.4.3, were implemented with an easily configurable preprocessor-defined variable. If the best swap in one round of Hill Climbing resulted in an equivalent score, a sideways move would be expended. This process would continue until a better solution is found or until there are no more allowable sideways moves. As mentioned in Section 3.4.3, sideways moves were implemented to reduce the probability of getting stuck in a “plateau.” The total amount of available sideways moves was set

to 500 because they were seen to be relatively inexpensive in their total added computation time after some testing.

Beyond the implementation of sideways moves, we also implemented random restarts. As outlined in Section 3.4.3, once Hill Climbing completes evaluation of the initial preordering, the program will generate multiple randomized preorderings that the Hill Climbing algorithm will process in the hopes that one of the resulting permutations will result in a reduced total backedge weight. After the implementation of the random restarts was completed, we noticed that it substantially increased the computation time of the Hill Climbing process as expected. One iteration of Hill Climbing was relatively quick to complete on a set of 130 teams or less, as shown in the base results in Section 5.2.3. The time for execution of one iteration of Hill Climbing also grew with the number of nodes in a permutation because of the increased number of swaps necessary to complete per iteration. Due to the large variance in the execution time for Hill Climbing, dependent on the number of teams in the dataset, we decided that there was not a “one size fits all” number of restarts that should be allowed.

In order to manage the variable time requirement for Hill Climbing depending on the number of restarts, we implemented a hybrid system of timing and hardcoded values. The new system for restarts in Hill Climbing used a hardcoded lower bound and upper bound for the number of restarts. For our testing, we set the lower bound for the number of restarts to 20 and the upper bound to 300. We reasoned that an adequate minimum amount of restarts was 20 because the difference in time required between 1 and 20 restarts did not seem significant enough to sacrifice the potential for a better random preordering. We also determined that any more than 300 restarts was unnecessary for the amount of time that would be required. Therefore, the Hill Climbing process would always run with at least 20 random restarts and at most 300 random restarts. For the restarts occurring in between these bounds, we implemented a configurable timing system that would check how long the Hill Climbing process had been executing and would determine if another random restart was allowed, where the execution time was measured from the start of the first preordering Hill Climbing evaluates. For example, before allowing restart number 21, the system would first check if the hill climb process had exceeded its configurable maximum amount of execution time before proceeding. If Hill Climbing had exceeded its allotted time after restart number 100, the system would stop computing random restarts. If the system reached the upper bound of 300 random restarts without surpassing the configured maximum amount of execution time, the system would still terminate Hill Climbing because the upper bound had been reached. The maximum execution time could also be configured to the needs of the user with the command line argument “--hctime”, which allowed testing using the Hill Climbing algorithm to be configured to the needs of the tester.

The final improvement made in the implementation of Hill Climbing was to extend the number of nodes checked in each swap to also check the n+2 neighbor as well as the n+1 neighbor. Essentially, each node would not only check a swap with its nearest neighbor but would also check the swap with the neighbor 2 positions away.

Figure 6: Initial Hill Climb implementation with N+1 neighbor comparison

Figure 7: Revised Hill Climb implementation with N+1 and N+2 comparisons

This process is shown in Figures 6 and 7 above. Note that the arrows on the top of the nodes delineate the position n+2 swaps and the arrows below the nodes delineate the position n+1 swaps. As shown in Figure 7, this process results in (n-1) • (n-2) swaps compared to (n-1) swaps as originally implemented. We decided that the decrease in runtime performance was worth the possibility of finding a better permutation by exploring more swaps.