— Day 23: Coprocessor Conflagration —

Last updated: 2018-01-09

Code version: 1e789e8

See more puzzles

Advent of Code

Session information

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: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.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     

other attached packages:
 [1] aocodeR_0.1.1      testthat_1.0.2     forcats_0.2.0      stringr_1.2.0      dplyr_0.7.4       
 [6] purrr_0.2.4        readr_1.1.1        tidyr_0.7.2        tibble_1.3.4       ggplot2_2.2.1.9000
[11] tidyverse_1.2.1   

loaded via a namespace (and not attached):
 [1] reshape2_1.4.2    haven_1.1.0       lattice_0.20-35   colorspace_1.3-2  htmltools_0.3.6  
 [6] base64enc_0.1-3   yaml_2.1.15       rlang_0.1.4       foreign_0.8-69    glue_1.2.0       
[11] modelr_0.1.1      readxl_1.0.0      bindrcpp_0.2      bindr_0.1         plyr_1.8.4       
[16] munsell_0.4.3     gtable_0.2.0      cellranger_1.1.0  rvest_0.3.2       evaluate_0.10.1  
[21] psych_1.7.8       knitr_1.17        parallel_3.4.2    curl_3.0          broom_0.4.2      
[26] Rcpp_0.12.14      scales_0.5.0.9000 backports_1.1.1   jsonlite_1.5      mnormt_1.5-5     
[31] digest_0.6.12     hms_0.4.0         stringi_1.1.6     grid_3.4.2        rprojroot_1.2    
[36] cli_1.0.0         tools_3.4.2       magrittr_1.5      lazyeval_0.2.1    crayon_1.3.4     
[41] pkgconfig_2.0.1   xml2_1.1.1        lubridate_1.7.1   assertthat_0.2.0  rmarkdown_1.8    
[46] httr_1.3.1        rstudioapi_0.7    R6_2.2.2          nlme_3.1-131      git2r_0.19.0     
[51] compiler_3.4.2   

Brief

You decide to head directly to the CPU and fix the printer from there. As you get close, you find an experimental coprocessor doing so much work that the local programs are afraid it will halt and catch fire. This would cause serious issues for the rest of the computer, so you head in and see what you can do.

The code it’s running seems to be a variant of the kind you saw recently on that tablet. The general functionality seems very similar, but some of the instructions are different:

set X Y sets register X to the value of Y. sub X Y decreases register X by the value of Y. mul X Y sets register X to the result of multiplying the value contained in register X by the value of Y. jnz X Y jumps with an offset of the value of Y, but only if the value of X is not zero. (An offset of 2 skips the next instruction, an offset of -1 jumps to the previous instruction, and so on.)

Only the instructions listed above are used. The eight registers here, named a through h, all start at 0.

The coprocessor is currently set to some kind of debug mode, which allows for testing, but prevents it from doing any meaningful work.

If you run the program (your puzzle input), how many times is the mul instruction invoked?

Let’s go

Packages & functions

library(devtools)
install_github("annakrystalli/aocodeR")

library(tidyverse)

── Attaching packages ─────────────────────────────────────────────────────────── tidyverse 1.2.1 ──
✔ ggplot2 2.2.1.9000     ✔ purrr   0.2.4     
✔ tibble  1.3.4          ✔ dplyr   0.7.4     
✔ tidyr   0.7.2          ✔ stringr 1.2.0     
✔ readr   1.1.1          ✔ forcats 0.2.0     
── Conflicts ────────────────────────────────────────────────────────────── tidyverse_conflicts() ──
✖ dplyr::filter() masks stats::filter()
✖ dplyr::lag()    masks stats::lag()

library(testthat)

Attaching package: ‘testthat’

The following object is masked from ‘package:dplyr’:

    matches

The following object is masked from ‘package:purrr’:

    is_null

library(aocodeR)

Input

input <- aoc_get_input(day = 23, cookie_path = paste0(rprojroot::find_rstudio_root_file(),
                                                 "/secrets/session_cookie.txt")) %>% 
    strsplit(., "\n") %>% unlist %>% 
    strsplit(., " ")
input %>% head

[[1]]
[1] "set" "b"   "84" 

[[2]]
[1] "set" "c"   "b"  

[[3]]
[1] "jnz" "a"   "2"  

[[4]]
[1] "jnz" "1"   "5"  

[[5]]
[1] "mul" "b"   "100"

[[6]]
[1] "sub"     "b"       "-100000"

Functions

value.Y <- function(Y){
    Y <- type.convert(Y, as.is = T)
    if(class(Y) == "character"){as.numeric(get(Y, envir = e))}else{as.numeric(Y)}
}
#expect_equal(,)
create_inst_frm <- function(f, envir = e){
    
    f$set <- function(X, Y){
        assign(X, value.Y(Y), envir = e)    
    }
    f$sub <- function(X, Y){
        assign(X, get(X, envir = e) - value.Y(Y), envir = e)
    }
    f$mul <- function(X, Y){
        assign(X, get(X, envir = e) * value.Y(Y), envir = e)
        f$mul_track <- f$mul_track + 1
    }
    f$jnz <- function(X, Y){
        if(value.Y(X) != 0){
            assign("i", (get("i", envir = f) + value.Y(Y) - 1), envir = f)}
    }
}
run_inst <- function(input, f) {
      
    f$i <- 1
    while((1 <= f$i & f$i <= length(input))){
            #cat("i = ", i, " --- f$i = ", f$i, "\n\n")
        #input[[f$i]]
        inst <- input[[f$i]]
        f[[inst[1]]](inst[2], inst[3])
        f$i <- f$i + 1
        #i <- i + 1
    }
    cat("END")
}

Test

#expect_equal(,)

deploy

e <- new.env(parent = emptyenv())
f <- new.env(parent = emptyenv())
map(.x = letters[1:8], .f = ~assign(.x, 0, envir = e))

[[1]]
[1] 0

[[2]]
[1] 0

[[3]]
[1] 0

[[4]]
[1] 0

[[5]]
[1] 0

[[6]]
[1] 0

[[7]]
[1] 0

[[8]]
[1] 0

f$mul_track <- 0
create_inst_frm(f)
run_inst(input, f)

[1] 6724

Success!

---

—- Part 2 —-

❗️ HELP NEEDED ❗️

Too slow or caught in infinite loop?

Too slow

Any feedback? let me know here!

---

Brief

Now, it’s time to fix the problem.

The debug mode switch is wired directly to register a. You flip the switch, which makes register a now start at 1 when the program is executed.

Immediately, the coprocessor begins to overheat. Whoever wrote this program obviously didn’t choose a very efficient implementation. You’ll need to optimize the program if it has any hope of completing before Santa needs that printer working.

The coprocessor’s ultimate goal is to determine the final value left in register h once the program completes. Technically, if it had that… it wouldn’t even need to run the program.

After setting register a to 1, if the program were to run to completion, what value would be left in register h?

Let’s go

Test

#expect_equal(,)

deploy

Deploying just ends up runing forever

e <- new.env(parent = emptyenv())
f <- new.env(parent = emptyenv())
map(.x = letters[1:8], .f = ~assign(.x, 0, envir = e))
f$mul_track <- 0
e$a <- 1

create_inst_frm(f)
run_inst(input, f)

Reproducible version of my input

dput(aoc_get_input(day = 23, cookie_path = paste0(rprojroot::find_rstudio_root_file(),
                                                 "/secrets/session_cookie.txt")))

"set b 84\nset c b\njnz a 2\njnz 1 5\nmul b 100\nsub b -100000\nset c b\nsub c -17000\nset f 1\nset d 2\nset e 2\nset g d\nmul g e\nsub g b\njnz g 2\nset f 0\nsub e -1\nset g e\nsub g b\njnz g -8\nsub d -1\nset g d\nsub g b\njnz g -13\njnz f 2\nsub h -1\nset g b\nsub g c\njnz g 2\njnz 1 3\nsub b -17\njnz 1 -23"

---

template based on the workflowr standalone template