Last updated: 2017-12-06
Code version: 9a2e62a
sessionInfo()R version 3.4.2 (2017-09-28)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.6
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.2 backports_1.1.1 magrittr_1.5 rprojroot_1.2
[5] tools_3.4.2 htmltools_0.3.6 yaml_2.1.15 Rcpp_0.12.14
[9] stringi_1.1.6 rmarkdown_1.8 knitr_1.17 git2r_0.19.0
[13] stringr_1.2.0 digest_0.6.12 evaluate_0.10.1A debugger program here is having an issue: it is trying to repair a memory reallocation routine, but it keeps getting stuck in an infinite loop.
In this area, there are sixteen memory banks; each memory bank can hold any number of blocks. The goal of the reallocation routine is to balance the blocks between the memory banks.
The reallocation routine operates in cycles. In each cycle, it finds the memory bank with the most blocks (ties won by the lowest-numbered memory bank) and redistributes those blocks among the banks. To do this, it removes all of the blocks from the selected bank, then moves to the next (by index) memory bank and inserts one of the blocks. It continues doing this until it runs out of blocks; if it reaches the last memory bank, it wraps around to the first one.
The debugger would like to know how many redistributions can be done before a blocks-in-banks configuration is produced that has been seen before.
For example, imagine a scenario with only four memory banks:
The banks start with 0, 2, 7, and 0 blocks. The third bank has the most blocks, so it is chosen for redistribution. Starting with the next bank (the fourth bank) and then continuing to the first bank, the second bank, and so on, the 7 blocks are spread out over the memory banks. The fourth, first, and second banks get two blocks each, and the third bank gets one back. The final result looks like this: 2 4 1 2.
Next, the second bank is chosen because it contains the most blocks (four). Because there are four memory banks, each gets one block. The result is: 3 1 2 3. Now, there is a tie between the first and fourth memory banks, both of which have three blocks. The first bank wins the tie, and its three blocks are distributed evenly over the other three banks, leaving it with none: 0 2 3 4. The fourth bank is chosen, and its four blocks are distributed such that each of the four banks receives one: 1 3 4 1. The third bank is chosen, and the same thing happens: 2 4 1 2. At this point, we’ve reached a state we’ve seen before: 2 4 1 2 was already seen. The infinite loop is detected after the fifth block redistribution cycle, and so the answer in this example is 5.
Given the initial block counts in your puzzle input, how many redistribution cycles must be completed before a configuration is produced that has been seen before?
library(tidyverse)
library(testthat)
library(aocodeR)input <- aoc_get_input(day = 6, cookie_path = paste0(rprojroot::find_rstudio_root_file(),
"/secrets/session_cookie.txt")) %>% strsplit("\t") %>% unlist %>% as.numericget_dup_conf <- function(input){
no_banks <- length(input)
banks <- input %>% setNames(1:no_banks)
conf <- paste(banks, collapse = "")
empty_banks <- rep(0, no_banks) %>% setNames(1:no_banks)
while(!(conf %>% duplicated() %>% any)){
highest <- which(banks == max(banks))[1]
blocks <- banks[highest]
banks[highest] <- 0
red_blocks <- (highest + 1):(highest + 1 + blocks - 1) %% length(banks)
red_blocks[red_blocks == 0] <- length(banks)
red_blocks <- red_blocks %>% table
red <- empty_banks
red[names(red_blocks)] <- red_blocks
banks <- banks + (red %>% as.vector())
conf <- c(conf, paste(banks, collapse = ""))
}
list(cycle = (length(conf) - 1), conf = conf)
}expect_equal(get_dup_conf( c(0,2,7,0))$cycle, 5)**SO SLOW!!, speeding it up would be an interesting challenge
out <- get_dup_conf(input)out$cycle[1] 14029Out of curiosity, the debugger would also like to know the size of the loop: starting from a state that has already been seen, how many block redistribution cycles must be performed before that same state is seen again?
In the example above, 2 4 1 2 is seen again after four cycles, and so the answer in that example would be 4.
How many cycles are in the infinite loop that arises from the configuration in your puzzle input?
out_test <- get_dup_conf( c(0,2,7,0))
expect_equal(out_test$conf[length(out_test$conf):1] %>% duplicated() %>% which(. == T) -1, 4)out$conf[length(out$conf):1] %>% duplicated() %>% which(. == T) -1[1] 2765