## 3 Methods
### Case-Based Reasoning Method for PIAC
#### 3.1.2 Training And Inference  
As in [18], the CBR method will consist of a repository of instance features, \(i\in I\), algorithm configurations, \(\theta\in\Theta\), and algorithm performance, \(KPI(i,\theta)\), stored as \((i,\theta,KPI(i,\theta))\) tuples (Figure 1). At runtime, the method assigns, for each new instance, the best configuration found for the most similar instance in the repository. This approach is also known as case-based reasoning [26] since it consists of a set of \"cases\" that are retained. Each case corresponds to a description of a past example with its performance and is represented by a tuple \((i,\theta,KPI(i,\theta))\). The repository of cases is also referred to as a case base. Next to [18; 26] is another successful implementation of the CBR method. The main differences between [26] and [18]--besides the fact that the method in [26] was developed in the context of algorithm selection rather than algorithm configuration--are that (a) [26] presents a portfolio-based method, whereas that in [18] is based on SIAC implementations on each problem instance to build the case base, and the method in (b) [26] was designed with the goal of identifying an optimal algorithm schedule, i.e., a schedule of algorithms that are to be run sequentially for a given problem instance, whilst the method in [18] can be used to either identify a unique \"best\" configuration or a set of \"good\" configurations to be run in parallel (this approach is, however, out of scope in this work). Finally, (c) [26] makes use of designed features and Euclidian distance calculated over that feature space to assess similarity between instances, whereas [18] makes use of Euclidean distance on a feature space determined via a deep embedding approach.  
In this work, we will focus on a case-based reasoning method where the case base is built via multiple SIAC implementations on each (training) problem instance. Furthermore, in our use case, we consider problem instances that vary only in the magnitude of the demand for each product type over a fixed period of time. Consequently, we will consider a set of features that emerge from the demand that characterize and differentiate each problem instance (See Section 5.2). As in [26], we will determine the similarity between problem instances using the Euclidean distance calculated over the resulting feature space.  
\begin{table}
\begin{tabular}{l c c c} \hline \hline
**Case Base Type** & **Case Base 1** & **Case Base 2** & **Case Base 3** \\ \hline Tuning budget per problem instance (s) & 200 & 400 & 600 \\ Total number of instances & 1000 & 1000 & 1000 \\ Total number of (instance, configuration) pairs & 4753 & 3344 & 3305 \\ Total number of unique configurations & 720 & 1437 & 1724 \\ CPU time in seconds a (default; best configuration) & (2.57; 2.19) & (2.57; 2.11) & (2.57; 2.05) \\ PAR-10 in seconds a (default; best configuration) & (20.82; 12.02) & (20.82; 11.10) & (20.82; 10.06) \\ Number of capped replications a (default; best configuration) & (2.03; 1.09) & (2.03; 1.00) & (2.03; 0.89) \\ Number of instances with no capped replications (default; best configuration) & (171; 508) & (171; 594) & (171; 650) \\ \hline \hline \end{tabular}  
* Per instance average.  
\end{table}
Table 1: Overview of collected samples.