{'fraction_non_alphanumeric': 0.029186762015632795, 'fraction_numerical': 0.009146848494927657, 'mean_word_length': 4.427346570397112, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Computer-Aided Generation of N-shift RWS

Generating schedules for shift workers is essential for many employers, whether the employer is a small or a large industrial complex, research laboratory, or other businesses involving shift works. Previous methods for creating rotational workforce schedules included interactions between the schedule maker and the algorithm, including defining the length of sequences of consecutive days of working shifts. In this method, an algorithm takes into account inputs (or constraints) from the schedule maker and then presents the possible solutions (incl. that all shifts must be filled, working hours per week, minimal resting time, etc.) in a first phase. The schedule maker can then select which solutions are most feasible to proceed with in the second phase, where the final schedules are then constructed and exported.


Introduction
Creating shift work schedules has always been a challenging task, especially such that are equal for all workers and at the same time distributes the shifts evenly and properly to prevent staff burnout. In order to achieve schedules for the workers that treats everyone equally, we will focus on so-called rotational workforce schedules (RWS:s). Rotational workforce schedules means that the schedule rotates after time, and hence, the other option would be static shift schedules.
In this project, we will do some literature review of what has been done in the past to establish methods for creating RWS:s followed by a different method to create them as well as follow the examples of creating them.

Literature review
In [1], the framework proposed consists of 4 steps (as quoted from [1] p. 88): • choosing a set of lengths of work blocks (a work block is a sequence of consecutive days of working shifts), • choosing a particular sequence of work and blocks of days-off amongst these that have optimal weekend characteristics, • enumerating possible shift sequences for the chosen work blocks subject to shift change constraints and bounds on sequences of shifts, and • assignment of sequences of shifts to blocks of work while fulfilling the staffing requirements.
The framework can thus, as stated in the article, be considered as a semiautomatic way of generating schedules as the algorithm is focused on interactions with the decision-maker who has to choose a fixed set of allowable lengths for work blocks. In [2], an algorithmic framework using a decomposition heuristic was constructed in order to quickly obtain feasible solutions for the rotational workforce scheduling problem. Here, similar to [1], the decision-maker has to set up a fixed set of work blocks. Their method is very powerful and can construct schedules for a large number of employees in a short amount of time.
In this project, we want to make the amount of interaction required less by allowing an algorithm present all possible solutions and hence giving the schedule maker all possible options for a given number of weeks to cycle over (which in this project is the same as the number of workers).

Computational Approach and Results
Looking back at what was done in previous work [1][2], we will use an approach similar to what was suggested in [1]: Each person has the same schedule, shifted by one week. Thus, the weeks are continuously shifted by one week for each worker until all workers have had 'each week'. This type of schedule can be created manually by a person by e.g. defining a set of work blocks ([1] [2]), but in this project an algorithm has been constructed that does the work of finding possible work blocks in order to reduce the workload for generating them. In this approach, we define the term 'shift arrays' which each represent a possible schedule, similar to work blocks. It has been divided into two phases, Boolean Shift Arrays (in which boolean shift arrays are generated) and From Boolean Shift Arrays to a RWS (in which a selected boolean shift array is shaped into its final RWS layout).

Boolean Shift Arrays (phase 1)
For simplicity, we begin by using boolean shift arrays with 1 meaning that the person works and 0 meaning that the person does not work. In order to impose some constraints on the shift arrays, we define the number of working days per week as n wd and number of weeks to cycle over as n W . This results in a shift array of length 7n W . For constructing the different combinations of the boolean array, we use Algorithm 1. Note that the "if shiftarray is ok " in Algorithm 1 is a combination of all constraints discussed in this section and are checked before a shiftarray is allowed to be appended to the list of shiftarrays, hence ensuring that all shiftarrays in the list follow these constraints.
Since each week also resembles a worker, the shift array can be set up as a matrix with 7 columns, each representing the days of a week. The columns can then be summed to achieve the shift occupancy (or how many people are working each shift). Thus, the algorithm only allows shift arrays to pass for which all shifts are occupied by at least one worker, with a shift represented by the first n wd days for each week. In order to extend to not only use single shifts but also 2-or 3-shifts, a simple logical reasoning was added into the algorithm. For N shifts per day, each day has to be filled with at least N workers.
The next input that the algorithm needs is the shift lengths and the weekly working hours per worker, defined as t s and t W , respectively. However, in order to generate "good schedules", an additional constraint will be needed in order to avoid all working days being clustered together. Hence, the constraint for weekly minimum single continuous resting time is added, defined as t r . The algorithm ensures that all passed shift arrays have at least this many hours of free-time for each week. The number of shifts n S per shift array is calculated by The reason for using ceiling function and not the floor function is simply the argument that it is better with a couple of more hours than fewer. In order to cluster days off (n c f ), the algorithm's GUI has an optional additional constraint that serves this purpose and simply does not allow shift arrays with 0:s in clusters less than this through. By using the input n W n wd as an iterable and n S as the length of subsequences of elements from the iterable, we use the same methodology as itertools [3] module in Python to create each shift array. The other inputs are used as constraints on whether the shift array should be appended to the array of shift arrays or trashed. The reasoning for not using the built-in module itertools.combinations [3] is that it returns all array combinations it could find. Without the constraints, the returned arrays become too large for a normal up-to-date computer's internal memory to handle.
With this, the final result is an array of shift arrays in which each shift array is filled with 7n S 1:s and n W (7 − n S ) 0:s whilst obeying the above mentioned constraints. The number of possible combinations C using Algorithm 1 can be expressed as: The parameters selected for the RWS is defined in Table 1. These values are then reflected in the algorithm's GUI for phase 1 can be seen in Figure 1. Note that the generated shift arrays can be browsed through using the slider or the numerical input field and that the shift arrays are constructed such that each week or worker (depending on the viewing angle) is represented in separate rows. Figure 2: The RWS:ing Application's algorithm's "phase 2 GUI" as launched from the "phase 1 GUI" and with the first Thursday's shift changed to an evening shift (left) and after some simple shift type permutations (right).

From Boolean Shift Arrays to RWS (phase 2)
In this phase, we have chosen to proceed with combination #35741 since it has two out of four weekends off (note the zeroes in the bottom table in Figure 1). By proceeding, the "phase 2 GUI" is launched with the selected array as input as can be seen in Figure 2 to the left.
The free days are all represented by zeroes whilst all other shifts (ones) are converted to the first defined shift type label. For N > 1, each shift can be replaced by another shift via dropdown menus. The GUI shows the number of shifts of each type each week or worker has and a table with the results, i.e. number of worker per shift and day. Shifts that are occupied have green background whilst shifts that are unoccupied have a red background.
If the continuous resting time between two assigned shifts is too low, the background colour of the second shift becomes red (e.g. a Friday day-shift after a Thursday evening-shift if the continuous resting time has to be at least 11 hours, as shown in Figure 2 to the left). With enough resting time in between shifts, the background of the second shift is be green.
After some simple shift types permutations, we end up with what is shown in Figure 2 (right). If the schedule is deemed as finished, the export button allows for the export of the finalized table into a txt-or CSV-file.
It is also possible to combine two or more shift arrays, e.g. two 4-week shift cycles to achieve a single 8-week shift cycle and which could result in that each shift is occupied by 2 workers. Such an example is shown in Figure 3, in which we have generated Boolean Arrays and set that free days have to be clustered in clusters of two (minimum). We then combined two 4-week shift cycles (#81 and #210), worked on them in phase 2, exported them as CSV-files and finally imported them into Microsoft Excel (2018) (where colouring work was done to highlight the weeks).

Benchmarking results
The algorithm benchmarking was done on an Apple MacBook Pro with the specifications as defined in Table 2. In the GUI, there is a "fast generation" checkbox which stops the algorithm from further calculations once the first 100 solutions have been found. This way, computation time can be lowered (in comparison to "full generation" which will go through all possible solutions from the boolean array). For our example, the time it took to complete decreased from 508.7 s (for a full generation) to 24.55 s (for the full generation) (see Table 3), which is a decrease in time by 95%.
We use the parameters defined in Table 1, with the exception of N and Shift types' labels. Note that for Table 3 and Table 4, the number (#) of weeks given is the minimum amount of weeks required for a full shift cycle in order to find solutions for the N-shift problems (with N = 1, 2, 3 for single-, two-and three-shifts, respectively). The free days clustering option is not selected for the benchmarking.  Plotting the benchmarking results, we find the logarithmic graph given in Figure 4. As can be seen, the computation time T C increases exponentially with the number of weeks in a shift cycle on average in accordance with T C (f ull) = exp(5.046 × n W ) × 9 × 10 −7

and
T C (f ast) = exp(4.254 × n W ) × 2 × 10 −6 for the full and fast generations on, respectively.

Conclusions
In this article, we have demonstrated that the constructed algorithm can generate schedules for different number of weeks to cycle over. The current issue is that the computational complexity (and hence the computation time) increases with the number of weeks, as can be seen in Table 4 and Figure 4. This means that for a higher amount of weeks in a shift cycle, this application will need development in order to have more efficient ways of finding the solutions and/or deployment of the application onto super-computers for generating the Boolean Arrays.
For up to 5 weeks in a shift cycle, it is, however, possible to use a generalpurpose computer such as the benchmarking MacBook Pro with specifications defined in Table 2. It has thus been demonstrated that the application can be used to generate 1, 2 and 3-shift schedules. Future development plans include adding an automated assignment function of shift types in phase 2, which would further strengthen the usability of this application.