Cada oferecimento de cada curso tem um repositório no GitHub, o que nos permite personalizar o conteúdo de uma turma sem afetar as outras. Mas essa granularidade cria um problema: o que fazer com o material que é comum a todas as turmas de um mesmo curso?

O problema

Imagine que existe uma turma A, que participou do curso R para Ciência de Dados III este ano, e uma turma B, que vai fazer o curso no ano que vem.

No passado nós copiávamos todo o conteúdo do repo A para o repo B, mas hoje em dia nós criamos os repositórios dos cursos com antecedência. Isso significa que qualquer alteração no material durante o oferecimento A precisaria ser propagada cuidadosamente para para o oferecimento B; infelizmente isso pode dar muito trabalho.

A solução que encontramos foi criar um repositório main para cada curso, ou seja, um repo central que contém apenas os slides. Assim, os repos das turmas só precisam hospedar o conteúdo que muda de um oferecimento para o outro (exercícios, anexos, comentários, etc.) e qualquer alteração nos slides imediatamente se aplica a todos os repos satélites.

Tudo funcionou perfeitamente bem até que decidimos fazer a primeira mudança na ementa de um curso. O problema desta estratégia é qualquer alteração no main é propagada para o passado; logo, se durante o oferecimento B resolvermos fazer uma reestruturação grande no material, a turma A vai perder a versão dela e ficará sem as suas referências.

O ideal seria ter uma maneira de atualizar os slides seletivamente, ou seja, manter a turma A na versão anterior do main e passar a B para a versão nova. Isso tudo sem quebrar os repos feitos com antecedência.

Submódulos

É aí que entram os submódulos. De acordo com a documentação, eles são essencialmente repos dentro de outros repos, ou seja, clonamos um repo (o submódulo) dentro de um repo hospedeiro. Inception.

Como eu posso usar submódulos para resolver meu problema com as turmas? Eu posso continuar usando o repo main para armazenar os slides, mas, ao invés de deixá-lo isolado, ele seria clonado como submódulo dentro do repo de cada turma. Neste arranjo, eu posso apontar o submódulo da turma A para a versão antiga do main e manter o da turma B apontado para a versão mais nova.

Para começar a usar submódulos, eu recomendo executar os seguintes comandos Git, pois eles garantem que o seu ambiente estará adequadamente preparado:

git config --global submodule.recurse true
git config --global push.recurseSubmodules check

Agora, dentro do repositório desejado, eu posso rodar o comando abaixo para trazer o repo main como um submódulo:

git submodule add https://github.com/curso-r/main-r4ds-3.git materiais/

Isso é muito similar a fazer um clone normal! No caso, o repositório main-r4ds-3 será clonado na pasta materiais/ no repo hospedeiro.

A partir de agora, eu posso usar sempre o repo hospedeiro, sem me preocupar com o main. Se eu fizer uma alteração na pasta materiais/, basta fazer um commit como qualquer outro! A atualização não vai para o repo da turma, mas sim para o main.

cd materiais/
git add -A
git commit -m "Alteração no main"
git push

Se voltarmos para a pasta um nível acima e executarmos git status, vamos ver que houve uma alteração em um arquivo chamado .gitmodules. Isso quer dizer que o submódulo foi atualizado no GitHub, não que ele foi atualizado no repo da turma.

Este é o pulo do gato: podemos atualizar o main quantas vezes quisermos, mas as atualizações só serão propagadas para o repo da turma se aceitarmos a alteração.

cd ../
git status
git add -A
git commit -m "Aceitando alterações do main"
git push

Isso permite que o repo de uma turma antiga como a A mantenha a sua referência a uma versão anterior do main ao mesmo passo que o repo das turmas novas podem ter suas referências atualizadas com facilidade. Se você quiser um exemplo de como fica uma referência no GitHub, dê uma olhada na demo de submódulos que fizemos na Curso-R: https://github.com/curso-r/202211-demo-submod.

E isso é tudo. Se você quiser uma demonstração em vídeo, a referência que eu usei foi essa aqui do Redhwan Nacef. Se você tiver qualquer dúvida, mande um email para mim e eu vou tentar ajudar o máximo possível. Até a próxima!

Introdução

Se você não sabe o que é uma lista, o conceito é na verdade bastante simples: elas funcionam como vetores, mas aceitam objetos de vários tipos (incluindo sub-listas). Abaixo estou criando uma lista l e exibindo a sua estrutura com a função str().

l <- list(
  objeto = "abc",
  vetor = c(1, 2, 3),
  lista = list(TRUE, FALSE)
)

str(l)
#> List of 3
#>  $ objeto: chr "abc"
#>  $ vetor : num [1:3] 1 2 3
#>  $ lista :List of 2
#>   ..$ : logi TRUE
#>   ..$ : logi FALSE

Repare em algumas propriedades das listas:

1. Podemos nomear os seus elementos, mas também podemos deixá-los sem nome nenhum. Isso também é possível com vetores, mas por algum motivo é mais comum ver listas nomeadas.

2. Diferentemente de vetores, podemos colocar elementos de qualquer comprimento dentro de uma lista.

3. Uma lista pode ter sub-listas (e sub-sub-listas, sub-sub-sub-listas, etc.) Isso não afeta em nada o seu comportamento, mas vamos precisar aprender a fazer indexações profundas.

Indexação

Acessar elementos de listas é um pouco mais complicado do que vetores. A base é a mesma: [i] retorna a i-ésima posição. O problema é que, nas listas, existe uma diferença entre a posição de um elemento e o elemento em si.

A i-ésima posição, em uma lista, sempre é uma lista. Para pegar o i-ésimo elemento, precisamos usar [[i]]! Alternativamente, em listas nomeadas, podemos usar ["nome"] e [["nome"]] (equivalente a $nome).

l[1]
#> $objeto
#> [1] "abc"

l[[1]]
#> [1] "abc"

l["objeto"]
#> $objeto
#> [1] "abc"

l[["objeto"]]
#> [1] "abc"

l$objeto
#> [1] "abc"

É aqui que começa o nosso problema. É conceitualmente difícil de entender a diferença entre uma posição e um elemento, ou seja, quando usar [] e quando usar [[]]. Para tentar ilustrar melhor, vamos usar a metáfora da rua.

Metáfora da rua

Vamos pensar em listas como ruas. Quando usarmos [] obteremos um trecho da rua e quando usarmos [[]] obteremos a família da casa correspondente. Seguindo a lógica da metáfora, um elemento-vetor é uma casa com vários moradores e um elemento-lista é uma vila que pode ter várias casas dentro.

Se quisermos pegar o trecho da rua que contém a primeira casa, podemos usar [i] ou ["nome"]. Ambos funcionam igual:

l[1]
l["objeto"]

Quando estamos falando de trechos da rua (segmentos da lista), podemos fazer seleções maiores. Abaixo, por exemplo, estamos selecionando as 2 últimas casas ou, alternativamente, todas as casas menos a primeira.

l[2:3]
l[c("vetor", "lista")]
l[-1]

Se quisermos selecionar os integrantes de uma casa (um elemento da lista), aí precisamos usar [[i]], [["nome"]] ou $nome. Note que a última opção é igual à seleção de colunas em um data frame.

l[[1]]
l[["objeto"]]
l$objeto

O processo para selecionar a família da casa 2 é idêntico, não importa que a casa 2 contém um vetor e a casa 1 contém um objeto simples.

l[[2]]
l[["vetor"]]
l$vetor

Idem para a casa 3, ou seja, a vila da nossa rua. O endereço é um só, mas dentro deste endereço temos uma nova casa 1 e uma nova casa 2.

l[[3]]
l[["lista"]]
l$lista

Se quisermos acessar a casa 1 da vila, podemos fazer indexação profunda. Para isso, basta colocar no final da nossa expressão mais um [1]! Funcionaria exatamente igual se nós quiséssemos pegar o primeiro elemento do vetor l$vetor.

l[[3]][1]
l[["lista"]][1]
l$lista[1]

Por fim, se quisermos pegar os integrantes da casa 1 da vila, basta adicionar um [[1]] na nossa indexação da vila analogamente ao que fizemos acima. No limite, não importa quantas sub-listas você tem, basta adicionar mais colchetes duplos conforme a necessidade.

l[[3]][[1]]
l[["lista"]][[1]]
l$lista[[1]]

Deu para entender agora? Me mande um email dizendo o que você achou desse exemplo e se você ficou com alguma dúvida. Até a próxima!

[…] Quando ordeno com arrange uma coluna, tem um valor que começa com A que aparece no final da lista!

O exemplo dela envolvia ordenar uma coluna de textos de uma tabela. A ordenação funcionava normalmente com sort(), mas não com arrange(). Veja a demonstração a seguir:

# Tabela exemplo
df <- tibble::tibble(bebida = c(
  "Cerveja",
  "Cachaça",
  "Água",
  "Vinho",
  "Gim"
))

# Tudo certo por aqui
sort(df$bebida)
#> [1] "Água"    "Cachaça" "Cerveja" "Gim"     "Vinho"

# Água fica por último!
dplyr::arrange(df, bebida)
#> # A tibble: 5 × 1
#>   bebida
#>   <chr>
#> 1 Cachaça
#> 2 Cerveja
#> 3 Gim
#> 4 Vinho
#> 5 Água

O nosso principal suspeito era o mesmo de qualquer problema com strings: encoding ou, em bom português, codificação. Contudo, desta vez ele não é o culpado; os caracteres do texto estão sendo interpretados e exibidos corretamente na saída de ambos os comandos, indicando que a causa da ordenação incorreta era outra.

Em busca de uma resposta, resolvi ler a documentação da função arrange(). Para a minha surpresa, descobri que ela tem um argumento .locale cujo valor por padrão é “o locale "C"”… Mas, o que isso significa? Normalmente vemos problemas de locale quando lidamos com tempo, porque essa é a opção que determina o formato de exibição das datas (DD/MM/AAAA no Brasil, MM/DD/AAAA nos EUA, etc.). Será que ela poderia ter alguma coisa a ver com a ordenação de textos?

Seguindo as pistas na documentação da arrange(), eventualmente cheguei na função stringi::stri_opts_collator(), que ajusta as opções do ICU Collator. E foi aí que tudo fez sentido.

Collation

Collation é um termo em inglês que descreve a compilação e ordenação de qualquer tipo de informação. A (surpreendente!) realidade é que cada país e idioma tem regras diferentes de ordenação alfabética, então é necessário escolher qual método de collation o R vai usar através do locale.

Para ilustrar a função do locale, imagine um problema mais simples: queremos que o R leia adequadamente uma data em alemão. Obviamente, ele não vai conseguir:

lubridate::dmy("6. März 2023")
#> Warning: All formats failed to parse. No formats found.
#> [1] NA

Para corrigir isso, precisamos especificar o argumento locale, indicando para o R que o conteúdo está escrito em alemão ("de_DE" para alemão da Alemanha):

lubridate::dmy("6. März 2023", locale = "de_DE")
#> [1] "2023-03-06"

O chocante é que o mesmo vale para a ordem alfabética. Nós geralmente não percebemos que tem algo errado com o locale da collation porque as regras de ordenação são muito parecidas em todos os países, mas existem diferenças sutis que causam problemas como o da Bea.

O programa que está tomando essas decisões de locale por trás dos panos se chama ICU; esta biblioteca do C é a base do stringi, o motor por trás do stringr e da arrange(). Como você pode imaginar, o locale padrão da ICU é o da linguagem C de programação, que coloca letras acentuadas no fim do alfabeto.

Sendo assim, podemos resolver a questão do arrange() especificando o nosso locale ("pt_BR" para português do Brasil):

dplyr::arrange(df, bebida, .locale = "pt_BR")
#> # A tibble: 5 × 1
#>   bebida
#>   <chr>
#> 1 Água
#> 2 Cachaça
#> 3 Cerveja
#> 4 Gim
#> 5 Vinho

É muito interessante ler a documentação do ICU sobre collation, pois ela deixa muito claro que é absolutamente impossível criar um locale que atenda às necessidades de todos os países:

• Em lituano, o “y” fica entre o “i” e o “k”.
• No espanhol tradicional, “ch” é tratado como uma única letra entre o “c” e o “d”.
• Em dinamarquês, “Å” é considerada uma letra separada que fica depois do “Z”.
• Na Suécia, “v” e “w” são consideradas variações de uma mesma letra.
• Em dicionários alemães, “öf” vem antes de “of”, mas em listas telefônicas a ordem preferida é a contrária.

O bom é que isso também esclarece o porquê da sort() funcionar, mas a arrange() não. Enquanto a segunda usa o locale "C" por padrão, a primeira usa o locale americano ("en_US" para inglês dos EUA)! Apesar de o locale americano nos causar problemas com datas, ele é muito parecido com o brasileiro na ordem alfabética e essencialmente ignora os acentos durante a collation.

Resumo

A função arrange() pode causar problemas na hora de ordenar textos em português. Isso ocorre porque o locale de collation padrão coloca todas as letras acentuadas no final do alfabeto, algo muito pouco usual no nosso idioma. A solução é especificar o argumento .locale = "pt_BR" para que ela use o locale apropriado ao nosso alfabeto.

O evento

Se você não está por dentro, o Advent of Code é um Calendário do Advento para quem programa. Entre 1º de dezembro e o Natal de cada ano, os organizadores vão disponibilizando 1 problema de programação por dia e o objetivo é chegar em 25 de dezembro com todos os 25 exercícios resolvidos.

Ano passado, no que eu chamei de Advent of R, eu me desafiei a de fato entrar no ritmo e resolver todos os problemas no dia em que eles fossem publicados, em R e documentando o processo no blog. Eu até consegui, mas foi extremamente difícil! Este ano eu vou pegar mais leve e fazer as coisas com mais calma.

Mas eu não queria deixar o evento passar em branco… Em 2022, minha contribuição para o Advent of R é um pacote para ajudar a comunidade toda 🎉

O pacote {aor}

O objetivo do {aor} é ajudar todo mundo que programa R a resolver o Advent of Code usando essa linguagem maravilhosa. Ele tem algumas funções que ajudam a baixar os desafios e as suas entradas o mais rápido possível.

Instalação

Você pode instalar a versão em desenvolvimento do {aor} do GitHub usando o comando abaixo:

# install.packages("devtools")
devtools::install_github("clente/aor")

Exemplo

O uso básico do {aor} gira em torno das funções day_start() e day_continue(). Por padrão, ambas as funções baixam os enunciados do dia atual, mas vou usar um dia fixo (01/12/2022) para ficar mais fácil de entender:

# Começar o problema do dia 01/12/2022 na pasta aoc2022/
aor::day_start("2022-12-01", "aoc2022/")
#> ✔ Fetched title.
#> ✔ Fetched puzzle.
#> ✔ Fetched input.

# Arquivos criados
fs::dir_tree("aoc2022/")
#> aoc2022/
#> └── 01_calorie_counting
#>     ├── input.txt
#>     └── puzzle.R

Essa é a cara do arquivo aoc2022/01_calorie_counting/puzzle.R (note que eu estou omitindo a maior parte das linhas do enunciado para que a saída não fique muito longa):

# --- Day 1: Calorie Counting ---
#
# Santa's reindeer typically eat regular reindeer food, but they need a
# lot of [magical energy](/2018/day/25) to deliver presents on Christmas.
# For that, their favorite snack is a special type of *star* fruit that
# only grows deep in the jungle. The Elves have brought you on their
# annual expedition to the grove where the fruit grows.
#
# ...
#
# Find the Elf carrying the most Calories. *How many total Calories is
# that Elf carrying?*

# Your input can be found on the file below:
input <- "aoc2022/01_calorie_counting/input.txt"

# Once you're done with part 1, run the following line to fetch part 2:
aor::day_continue("2022-12-01", "aoc2022/01_calorie_counting/puzzle.R")

Quando você resolver a parte 1 do exercício, você pode rodar a última linha do arquivo para automaticamente baixar a parte 2 ali mesmo!

aor::day_continue("2022-12-01", "aoc2022/01_calorie_counting/puzzle.R")
#> ✔ Fetched puzzle.

E essa é a cara do arquivo logo depois de rodar day_continue() (de novo omitindo a maior parte das linhas):

# --- Day 1: Calorie Counting ---
#
# Santa's reindeer typically eat regular reindeer food, but they need a
# lot of [magical energy](/2018/day/25) to deliver presents on Christmas.
# For that, their favorite snack is a special type of *star* fruit that
# only grows deep in the jungle. The Elves have brought you on their
# annual expedition to the grove where the fruit grows.
#
# ...
#
# Find the Elf carrying the most Calories. *How many total Calories is
# that Elf carrying?*

# Your input can be found on the file below:
input <- "aoc2022/01_calorie_counting/input.txt"

# Once you're done with part 1, run the following line to fetch part 2:
aor::day_continue("2022-12-01", "aoc2022/01_calorie_counting/puzzle.R")

# --- Part Two ---
#
# By the time you calculate the answer to the Elves' question, they've
# already realized that the Elf carrying the most Calories of food might
# eventually *run out of snacks*.
#
# ...
#
# Find the top three Elves carrying the most Calories. *How many Calories
# are those Elves carrying in total?*

Espero que vocês aproveitem o Advent of R com o {aor}! Boa sorte e boas festas 🎄

De forma bem resumida, ao instalar o RStudio Server em um servidor, você nunca mais precisa se preocupar com SSH. Todo o acesso ao servidor passa a ser através de uma interface web que é idêntica ao RStudio normal, o que significa que você pode programar usando os recursos do seu servidor, mas com a mesmíssima IDE que você já usa no dia-a-dia.

Mesmo depois que eu passei a usar o VS Code para programar R no meu computador, eu continuei usando o RStudio Server no servidor da empresa. Mês passado, entretanto, eu descobri uma funcionalidade incrível do VS Code que me permitiu abandonar de uma vez por todas o RStudio: o VS Code Remote Development.

Diferentemente do RStudio Server, o Remote Development não é instalado no servidor, mas sim no seu computador. Essa ferramenta usa SSH por trás dos panos para trazer todos os arquivos do servidor até o seu VS Code local e, quando você executa algum comando, ela faz o caminho reverso para rodar o código no servidor.

Isso não é nada novo! Todo mundo que já usou SSH alguma vez na vida e precisou abrir um editor de texto remoto (vim ou nano), provavelmente não vai estranhar o modo como o Remote Development funciona. A única diferença é que o RD traz o código até o VS Code e não até o seu terminal.

Há vantagens e desvantagens nessa abordagem: por um lado, o servidor não vai precisar gastar recursos renderizando a interface do RStudio Server, mas por outro, não tem um jeito muito simples de passar o seu acesso para outra pessoa (dado que não é só um site que você acessa de qualquer lugar). A melhor solução é sempre a que se encaixa melhor no seu fluxo de trabalho.

O processo para configurar o RD é bastante simples e pode ser encontrado inteiramente na página do Remote development via SSH. Em resumo, você precisa instalar a extensão, conectar com o seu servidor via SSH e configurar as suas extensões para o ambiente remoto.

O passo mais complexo é o último, mas mesmo ele é até que bastante intuitivo. Na época eu tive dificuldade de entender que as minhas extensões não funcionavam no modo remoto porque eu precisava instalá-las de novo! Essencialmente, eu precisava configurar a extensão do R para funcionar com os programas do servidor e não mais os da minha máquina.

E isso é tudo! Espero que este post tenha sido útil para apresentar uma funcionalidade muito legal da IDE que eu tenho usado todos os dias pelos últimos meses. Até a próxima :)

P.S.: Além da solução que eu apresentei, há ainda duas outras: o RStudio Workbench (um produto pago da RStudio) passou a permitir o uso da interface do VS Code e, recentemente, a Microsoft anunciou o VS Code Server, que eu ainda não tive oportunidade de testar.

Atualmente há 2 famílias de funções principais: cards e sets. As outras 4 (bulk_data, catalogs, rulings, e symbols) são majoritariamente auxiliares.

# Instalar o scryr
install.packages("scryr")

# Carregar o scryr com o dplyr
library(dplyr)
library(scryr)

Cartas

Essa família é, de longe, a mais complicada de entender. Antes de usá-la, lembre-se de ler a documentação completa da scry_cards()! Para os curiosos, outras informações relevantes podem ser encontradas em vignette("syntax") (Query Syntax) e em vignette("layouts")` (Layouts and Faces).

A função mais importante aqui é scry_cards(). Ela retorna um data frame de cartas dada uma busca.

# Vampiros lendários
vampires <- scry_cards("t:vampire t:legend")

# Há muitas, muitas colunas
print(vampires)
#> # A tibble: 48 × 70
#>    id         name     set   lang  colors color_identity mana_cost   cmc
#>    <chr>      <chr>    <chr> <chr> <list> <list>         <chr>     <dbl>
#>  1 913dd06f-… Anje Fa… c19   en    <chr … <chr [2]>      {1}{B}{R}     3
#>  2 1bfac4ab-… Anje, M… vow   en    <chr … <chr [2]>      {2}{B}{R}     4
#>  3 b8630ae1-… Anowon,… voc   en    <chr … <chr [1]>      {3}{B}{B}     5
#>  4 bca84fc4-… Anowon,… znc   en    <chr … <chr [2]>      {2}{U}{B}     4
#>  5 e811f37a-… Arvad t… dom   en    <chr … <chr [2]>      {3}{W}{B}     5
#>  6 213ad4ba-… Ascenda… hop   en    <chr … <chr [1]>      {4}{B}{B}     6
#>  7 e5fb44d7-… Baron S… me1   en    <chr … <chr [1]>      {5}{B}{B…     8
#>  8 487e843f-… Crovax … tpr   en    <chr … <chr [1]>      {2}{B}{B}     4
#>  9 2c58ce5e-… Drana, … c17   en    <chr … <chr [1]>      {3}{B}{B}     5
#> 10 31d0c37f-… Drana, … jmp   en    <chr … <chr [1]>      {1}{B}{B}     3
#> # … with 38 more rows, and 62 more variables: oracle_text <chr>,
#> #   power <chr>, toughness <chr>, type_line <chr>, edhrec_rank <int>,
#> #   keywords <list>, layout <chr>, legalities <list>, oversized <lgl>,
#> #   reserved <lgl>, oracle_id <chr>, mtgo_id <int>,
#> #   multiverse_ids <list>, tcgplayer_id <int>, cardmarket_id <int>,
#> #   uri <chr>, scryfall_uri <chr>, rulings_uri <chr>,
#> #   prints_search_uri <chr>, artist <chr>, artist_ids <list>, …

Note que várias colunas são list-columns com dados aninhados. Isso é uma consequência do modelo de dados do Scryfall e é a principal razão do scryr precisar de tibbles para funcionar. Mas não se preocupe! Todos os dados são consistentes e bem documentados.

# Pegar cartas relacionadas a Anje
vampires %>%
  filter(name == "Anje, Maid of Dishonor") %>%
  pull(all_parts)
#> [[1]]
#> # A tibble: 2 × 6
#>   object       id         component  name     type_line   uri
#>   <chr>        <chr>      <chr>      <chr>    <chr>       <chr>
#> 1 related_card 1bfac4ab-… combo_pie… Anje, M… Legendary … https://api.s…
#> 2 related_card a6f374bc-… token      Blood    Token Arti… https://api.s…

# Pegar a identidade de cor da Anje
vampires %>%
  filter(name == "Anje Falkenrath") %>%
  pull(color_identity)
#> [[1]]
#> [1] "B" "R"

Também há várias funções “no singular”, ou seja, funções que retornam 1 carta ao invés de muitas. Elas são scry_card() e suas irmãs, todos métodos que encontram uma carta dado um certo identificador.

# Usando ID
scry_card("913dd06f-ed2f-4128-9c9d-9cd0d8a55425")$name
#> [1] "Anje Falkenrath"

# Usando nome
scry_card_name("Anje Falkenrath")$name
#> [1] "Anje Falkenrath"

# Usando um número de colecionador e um set
scry_card_number(37, "c19")$name
#> [1] "Anje Falkenrath"

# Pegar um commander vampiro aleatório
scry_card_random("t:vampire t:legend")$name
#> [1] "Vito, Thorn of the Dusk Rose"

Se você não tiver certeza de qual carta você está procurando, não se preocupe. O Scryfall também tem um endpoint que tenta autocompletar o nome de uma carta e o scryr disponibiliza isso para que você nem precise sair do R para procurar uma carta.

# Olha lá ela
autocomplete_name("falken")[12]
#> [1] "Anje Falkenrath"

Sets

A outra família principal retorna informações sobre sets. De novo há muitas list-columns, mas, novamente, todas são tratadas consistentemente; seguindo cards, sets também tem uma função “plural” e uma função “singular”. Note que scry_cards() é a única que pode filtrar seus resultados com o argumento q.

# Pegar todos os sets
scry_sets()
#> # A tibble: 721 × 19
#>    id     code  name  uri   scryfall_uri search_uri released_at set_type
#>    <chr>  <chr> <chr> <chr> <chr>        <chr>      <date>      <chr>
#>  1 a6012… tunf  Unfi… http… https://scr… https://a… 2022-04-01  token
#>  2 b314f… unf   Unfi… http… https://scr… https://a… 2022-04-01  funny
#>  3 b11b2… pw22  Wiza… http… https://scr… https://a… 2022-03-05  promo
#>  4 5bd03… tnec  Neon… http… https://scr… https://a… 2022-02-18  token
#>  5 8bb11… tneo  Kami… http… https://scr… https://a… 2022-02-18  token
#>  6 5b4d9… nec   Neon… http… https://scr… https://a… 2022-02-18  command…
#>  7 59a20… neo   Kami… http… https://scr… https://a… 2022-02-18  expansi…
#>  8 78a7f… cc2   Comm… http… https://scr… https://a… 2022-01-28  command…
#>  9 5c163… dbl   Inni… http… https://scr… https://a… 2022-01-28  draft_i…
#> 10 8a673… y22   Alch… http… https://scr… https://a… 2021-12-09  expansi…
#> # … with 711 more rows, and 11 more variables: card_count <int>,
#> #   parent_set_code <chr>, digital <lgl>, nonfoil_only <lgl>,
#> #   foil_only <lgl>, icon_svg_uri <chr>, tcgplayer_id <int>,
#> #   mtgo_code <chr>, arena_code <chr>, block_code <chr>, block <chr>

# Pegar um único set com um código
scry_set("vow")
#> # A tibble: 1 × 19
#>   id    code  name  mtgo_code arena_code tcgplayer_id uri   scryfall_uri
#>   <chr> <chr> <chr> <chr>     <chr>             <int> <chr> <chr>
#> 1 8144… vow   Inni… vow       vow                2862 http… https://scr…
#> # … with 11 more variables: search_uri <chr>, released_at <date>,
#> #   set_type <chr>, card_count <int>, printed_size <int>,
#> #   digital <lgl>, nonfoil_only <lgl>, foil_only <lgl>,
#> #   block_code <chr>, block <chr>, icon_svg_uri <chr>

Outras Famílias

Todas as outras famílias retornam muito menos informações do que as acima. Deixo vocês com uma pequena demontração do que o resto do scryr pode fazer:

# Pegar informações de um catálogo
head(scry_catalog("keyword-actions"))
#> [1] "Meld"        "Bolster"     "Clash"       "Fateseal"
#> [5] "Manifest"    "Monstrosity"

# Pegar regras de uma carta
scry_ruling("913dd06f-ed2f-4128-9c9d-9cd0d8a55425")
#> # A tibble: 1 × 4
#>   oracle_id                            source published_at comment
#>   <chr>                                <chr>  <date>       <chr>
#> 1 4dab6a96-4376-4aea-983d-406167993214 wotc   2019-08-23   If you disca…

# Pegar informações sobre símbolos
scry_symbols()
#> # A tibble: 34 × 11
#>    symbol colors   cmc loose_variant english           gatherer_alterna…
#>    <chr>  <list> <dbl> <chr>         <chr>             <list>
#>  1 {X}    <NULL>   0   X             X generic mana    <chr [2]>
#>  2 {Y}    <NULL>   0   Y             Y generic mana    <NULL>
#>  3 {Z}    <NULL>   0   Z             Z generic mana    <NULL>
#>  4 {0}    <NULL>   0   0             zero mana         <chr [1]>
#>  5 {½}    <NULL>   0.5 ½             one-half generic… <chr [1]>
#>  6 {1}    <NULL>   1   1             one generic mana  <chr [1]>
#>  7 {2}    <NULL>   2   2             two generic mana  <chr [1]>
#>  8 {3}    <NULL>   3   3             three generic ma… <chr [1]>
#>  9 {4}    <NULL>   4   4             four generic mana <chr [1]>
#> 10 {5}    <NULL>   5   5             five generic mana <chr [1]>
#> # … with 24 more rows, and 5 more variables: transposable <lgl>,
#> #   represents_mana <lgl>, appears_in_mana_costs <lgl>, funny <lgl>,
#> #   svg_uri <chr>

# Processar um custo de mana
parse_cost("2g2")$cost
#> [1] "{4}{G}"

# Pegar nomes dos arquivos de massa
scry_bulk_files()$name
#> [1] "Oracle Cards"   "Unique Artwork" "Default Cards"  "All Cards"
#> [5] "Rulings"

# Baixar (e processar) todas as regras da base do Scryfall
scry_bulk_file("Rulings")
#> # A tibble: 44,486 × 4
#>    oracle_id                            source published_at comment
#>    <chr>                                <chr>  <date>       <chr>
#>  1 0004ebd0-dfd6-4276-b4a6-de0003e94237 wotc   2004-10-04   If there ar…
#>  2 0007c283-5b7a-4c00-9ca1-b455c8dff8c3 wotc   2019-08-23   The "comman…
#>  3 0007c283-5b7a-4c00-9ca1-b455c8dff8c3 wotc   2019-08-23   Certain car…
#>  4 0007c283-5b7a-4c00-9ca1-b455c8dff8c3 wotc   2019-08-23   If your com…
#>  5 000e5d65-96c3-498b-bd01-72b1a1991850 wotc   2004-10-04   The target …
#>  6 0012bc78-e69d-4a67-a302-e5fe0dfd4407 wotc   2019-05-03   A land norm…
#>  7 00187de2-bc48-4137-97d8-a9a0fafc76c1 wotc   2019-01-25   You can alw…
#>  8 00187de2-bc48-4137-97d8-a9a0fafc76c1 wotc   2019-01-25   Pteramander…
#>  9 00187de2-bc48-4137-97d8-a9a0fafc76c1 wotc   2019-01-25   If a creatu…
#> 10 001c6369-df13-427d-89df-718d5c09f382 wotc   2009-05-01   Vedalken He…
#> # … with 44,476 more rows

Um dos melhores artigos que eu já li na internet se chama This Page is Designed to Last, escrito por Jeff Huang, um professor de Ciência da Computação da Brown University. Nele, Jeff discute seus recentes problemas com apodrecimento de links e como é cada vez mais difícil confiar que uma página permanecerá de pé depois de alguns anos.

As ferramentas de desenvolvimento web têm ficado cada vez mais complexas e, ao mesmo tempo, a dificuldade de manter seu próprio conteúdo tem aumentado proporcionalmente. Qual framework de JavaScript devemos usar hoje? React? Vue? Angular? Essas ferramentas vão funcionar daqui 10 anos?

Muito por causa dessa dificuldade de conseguir manter seu próprio conteúdo vivo, temos trocado a web pública por aplicativos de celular, redes sociais e sites “pré-prontos”. Um dia o Instagram, o Twitter e o Wix vão sumir, inevitavelmente deixando seu antigo conteúdo sem lar.

Quanta confiança você tem de que aquele perfil que você retuitou semana passada vai continuar no ar daqui 5 anos? E se aquela página tivesse conteúdo valioso para a sua pesquisa? O próprio Jeff nos dá algumas dicas de como criar páginas feitas para durar:

1. Use HTML/CSS puros.
2. Não minimize HTML.
3. Prefira uma página ao invés de várias.
4. Acabe com o hotlinking.
5. Use fontes nativas.
6. Comprima suas imagens.
7. Reduza o risco de links quebrados.

O seu site vai ficar mais feioso? Possivelmente. O seu site vai ficar menos moderno? Quase com certeza. O processo de manutenção vai ficar menos automatizado? No início é muito provável que sim. Mas quais são os registros da Antiguidade que ainda temos? Não são os belos tecidos ou as meticulosas esculturas de madeira, são os textos talhados em pedra. Os nossos sites precisam ser construídos com essa mentalidade.

Fazendo a Minha Parte

Agora vamos falar sobre a página na qual você se encontra. Em primeiro lugar eu tentei seguir ao máximo as dicas do Jeff, removendo a maior parte das minimizações, optando majoritariamente por fontes nativas, hospedando minhas próprias imagens, usando HTTPS e assim por diante. É verdade que eu uso o Hugo (será que esse link ainda funciona?) para gerar os HTMLs dos posts a partir de arquivos Markdown, mas isso só afeta a minha criação de novo conteúdo; tudo que já está aqui não tem motivo para mudar se o Hugo parar de funcionar.

Mas eu tentei ir além. Em respeito às suas segurança e privacidade, eu também removi todo o JavaScript do meu site. Pode testar! Desabilite o JS, investigue as requisições realizadas, tudo deve continuar igual. Até o syntax highlighting e a formatação de fórmulas são completamente estáticos. P.S.: se a fórmula não estiver renderizada corretamente, basta atualizar seu navegador.

# Nada de JavaScript aqui:
f <- function(x) 2 * x

Em retrospecto, o trabalho foi até menor do que eu imaginava. Tanto o Chroma quanto o KaTeX permitem baixar os seus CSSs e fontes para que eles possam formatar código/matemática sem a necessidade de um plugin JavaScript.

Na verdade, eu removi todas as requisições externas do site. Desde as imagens até as fontes e stylesheets, os recursos que utilizo são todos servidos junto com a página. Isso evita vulnerabilidades e rastreamento indesejado, além de acelerar um pouco a navegação.

E, falando em rastreamento indesejado, obviamente não estou usando nenhum serviço da laia do Google Analytics. Para confirmar essa alegação, basta olhar os resultados do Blacklight para este domínio.

Agora, sobre a velocidade da navegação, eu particularmente me esforcei bastante para que o site fosse leve e responsivo. Ter um CSS minimalista e usar fontes nativas ajudou muito nisso, mas várias outras otimização tiveram que ser realizadas. No momento em que escrevo, o site tem todas as notas máximas no Google Lighthouse.

Entretanto, a minha maior conquista foi no que toca a segurança e privacidade da navegação. Seguindo as dicas da Mozilla, meu blog também atingiu a nota máxima do Mozilla Observatory (e em todos os outros índices externos que eles utilizam).

Este último passo deu mais trabalho do que eu esperava. Uma das sugestões do Observatory é remover absolutamente todos os CSS inline, o que é simples para a maior parte do conteúdo, exceto para o KaTeX. No final eu acabei tendo que criar um script para limpar esses estilos e passá-los automaticamente para um arquivo CSS separado.

Em resumo, navegando aqui você:

• Receberá apenas tráfego criptografado via HTTPS.
• Não vai sentir nem cheiro de JavaScript.
• Não fará nenhuma requisição para outros domínios por trás dos panos.
• Não estará sendo rastreado por cookies ou analytics.
• Terá a melhor experiência de desempenho que eu puder prover.
• Estará protegido pelos mais modernos padrões de segurança web.

Enfim, este é o meu site de pedra. Sinta-se em casa.

Atualização de 2023-01-17

Desde que eu escrevi este post, muita coisa mudou no site! Eu troquei de CSS mais de uma vez, dei uma bela simplificada na estrutura, removi as fontes externas e adicionei algumas otimizações que se tornaram possíveis só nos últimos meses. O principal, entretanto, continua igual: sem rastreadores, leve e sem vulnerabilidades.

Na verdade, estou escrevendo esta atualização para falar só do KaTeX. Apesar de ele atender aos meus requisitos, a gambiarra para tirar os CSS inlines estava saindo do controle… Era difícil demais de manter e os arquivos CSS resultantes começaram a ficar pesados.

Mas, por pura sorte, eu tentei resolver esse problema literalmente uma semana depois de o MathML começar a ser suportado pelo Chrome. Para quem não conhece, o MathML permite escrever equações matemáticas usando elementos HTML normais como <math>; isso resolve perfeitamente o meu problema porque é o navegador quem acerta o estilo da fonte, sem a necessidade de um monte de CSS por fora. Basta usar um conversor de LaTeX para MathML e pronto!

Sendo assim, se alguma equação do site não estiver aparecendo direito para você, basta atualizar seu navegador que o problema provavelmente irá embora. Viva o MathML!

Meu objetivo com o Advent of R foi resolver todos os problemas do Advent of Code 2021 em R e documentar o processo. Todo dia entre 01/12/2021 e 25/12/2021 eu vou resolvi o novo problema, documentei a minha solução e subi os meus scripts completos para um repositório público no GitHub.

Abaixo, cada seção representa um item de um dia do advent. Cada exercício foi individualmente resolvido no blog da Curso-R no dia correto, então todos começam com a minha opinião daquele exercício. Boas festas e bom código!

Varredura de Sonar (A)

A parte 1 do primeiro exercício do AoC envolve ler uma lista de números e ver quantas vezes os valores aumentam em relação ao anterior. Em linguagem matemática, precisamos avaliar quantas vezes $x_i>x_{i-1\text{}}$ .

Por exemplo, suponha a seguinte lista:

# 199
# 200
# 208
# 210
# 200
# 207
# 240
# 269
# 260
# 263

Nesse caso, precisamos comparar cada número com o da linha anterior e verificar se ele representa que a série aumentou, diminuiu ou manteve-se constante.

# 199 (NA)
# 200 (aumentou)
# 208 (aumentou)
# 210 (aumentou)
# 200 (diminuiu)
# 207 (aumentou)
# 240 (aumentou)
# 269 (aumentou)
# 260 (diminuiu)
# 263 (aumentou)

Tendo isso, podemos concluir que houve 7 aumentos na série exemplo e essa seria a resposta do problema.

O meu código para resolver o exercício ficou bem enxuto. Bastou ler a lista de número do arquivo disponibilizado como uma tabela e comparar seus valores com o seu dplyr::lag(); depois disso um dplyr::summarise() contou o número de TRUEs ignorando NAs.

"data-raw/01a_sonar_sweep.txt" |>
  readr::read_table(col_names = "depth") |>
  dplyr::mutate(
    prev_depth = dplyr::lag(depth),
    is_deeper = depth > prev_depth
  ) |>
  dplyr::summarise(n_deeper = sum(is_deeper, na.rm = TRUE)) |>
  dplyr::pull(n_deeper)
#> [1] 1228

Varredura de Sonar (B)

A segunda parte, entretanto, aumenta (com o perdão do trocadilho) a dificuldade. Dessa vez precisamos somar uma janela de 3 valores e comparar com a próxima janela, ou seja, verificar quantas vezes ${\sum }_{k=i}^{i+2}{x}_k\ge {\sum }_{k=i-1}^{i+1}{x}_k$ .

Observe como as janelas funcionam:

# 199  A
# 200  A B
# 208  A B C
# 210    B C D
# 200  E   C D
# 207  E F   D
# 240  E F G
# 269    F G H
# 260      G H
# 263        H

Nesse exemplo precisaríamos somar os números da janela A (199, 200, 208) e testar se isso é maior que a soma dos números da janela B (200, 208, 210). Então compararíamos B com C, C com D e assim por diante.

# A: 607 (NA)
# B: 618 (aumentou)
# C: 618 (não mudou)
# D: 617 (diminuiu)
# E: 647 (aumentou)
# F: 716 (aumentou)
# G: 769 (aumentou)
# H: 792 (aumentou)

Alterando o código da primeira parte, eu criei as janelas usando dplyr::lead() e depois comparei as somas utilizando o mesmo dplyr::lag(). Mais uma vez o dplyr::summarise() contou o número de TRUEs ignorando NAs.

"data-raw/01b_sonar_sweep.txt" |>
  readr::read_table(col_names = "depth") |>
  dplyr::mutate(
    depth1 = dplyr::lead(depth, n = 1),
    depth2 = dplyr::lead(depth, n = 2),
    sum_depth = depth + depth1 + depth2,
    prev_sum_depth = dplyr::lag(sum_depth),
    is_deeper = sum_depth > prev_sum_depth
  ) |>
  dplyr::summarise(n_deeper = sum(is_deeper, na.rm = TRUE)) |>
  dplyr::pull(n_deeper)
#> [1] 1257

Mergulhe (A)

A parte 1 do segundo dia do AoC pede para lermos uma lista de comandos para um submarino e calcular a sua posição final. Os comandos possíveis são forward X (soma X à posição horizontal), up X (subtrai X da profundidade) e down X (soma X à profundidade), então precisamos fazer um dplyr::group_by(command == "forward") para que um grupo represente a posição horizontal e um represente a profundidade.

Para concluir o código, como a resposta final é a posição horizontal multiplicada pela profundidade, temos que fazer um prod() ao final:

"data-raw/02a_dive.txt" |>
  readr::read_delim(" ", col_names = c("command", "x")) |>
  dplyr::mutate(x = ifelse(command == "up", -x, x)) |>
  dplyr::group_by(command == "forward") |>
  dplyr::summarise(x = sum(x)) |>
  dplyr::summarise(x = prod(x)) |>
  dplyr::pull(x)
#> [1] 1727835

Mergulhe (B)

A parte 2 complica um pouco a nossa vida. Os mesmos comandos agora possuem outro significado:

• down X aumenta a mira em X unidades
• up X diminui a mira em X unidades.
• forward X faz duas coisas:
  • Aumenta a posição horizontal em X unidades.
  • Aumenta a profundidade em X vezes a mira atual.

O meu código da primeira parte não permitiria resolver isso de forma eficiente. Minha solução foi fazer uma cumsum() da posição horizontal e uma da mira, que são as partes mais simples. Depois eu calculei a profundidade com cumsum(aim * x) (dado que a mira tinha sido calculada no passo anterior).

A saída, mais uma vez é o produto entre a posição horizontal e a profundidade. Dessa vez a resposta vai estar na última linha da tabela, então o código precisa de um tail(1).

"data-raw/02a_dive.txt" |>
  readr::read_delim(" ", col_names = c("command", "x")) |>
  dplyr::mutate(
    horizontal = ifelse(command == "forward", x, 0),
    horizontal = cumsum(horizontal),
    aim = ifelse(command == "down", x, 0),
    aim = ifelse(command == "up", -x, aim),
    aim = cumsum(aim),
    depth = ifelse(command == "forward", aim * x, 0),
    depth = cumsum(depth),
    output = horizontal * depth
  ) |>
  utils::tail(1) |>
  dplyr::pull(output)
#> [1] 1544000595

Diagnóstico Binário (A)

Na primeira parte do terceiro dia do AoC somos apresentados aos diagnósticos do submarino. Cada linha é composta por um número binário e precisamos carclular, a partir deles, os índices gama e épsilon.

# 00100
# 11110
# 10110
# 10111
# 10101
# 01111
# 00111
# 11100
# 10000
# 11001
# 00010
# 01010

Cada bit do fator gama é igual ao valor mais comum do bit correspondente na entrada, enquanto o épsilon funciona ao contrário. No exemplo acima, o primeiro bit mais comum é 1 e o segundo é 0, então o índice gama começará com 10… e o índice épsilon começará com 01…

O meu código quebra os bits da entrada com tidyr::separate() e calcula o valor mais frequente com names(sort(-table(.x)))[1] (a moda estatística). É importante lembrar que épsilon é o oposto, então eu troquei todos os bits de gama com stringr::str_replace_all(). A resposta final é a multiplicação de gama por épsilon na base decimal.

"data-raw/03a_binary_diagnostic.txt" |>
  readr::read_table(col_names = "reading") |>
  tidyr::separate(reading, paste0("B", 0:12), "") |>
  dplyr::select(-B0) |>
  dplyr::summarise_all(~names(sort(-table(.x)))[1]) |>
  tidyr::unite("gamma", dplyr::everything(), sep = "") |>
  dplyr::mutate(
    epsilon = gamma |>
      stringr::str_replace_all("0", "!") |>
      stringr::str_replace_all("1", "0") |>
      stringr::str_replace_all("!", "1") |>
      strtoi(base = 2),
    gamma = strtoi(gamma, base = 2),
    output = gamma * epsilon
  ) |>
  dplyr::pull(output)

Diagnóstico Binário (B)

O segundo item desse dia foi o mais difícil de todos, ainda mais considerando que eu tento resolver tudo em apenas uma pipeline. Usando os mesmos dados, precisamos obter a taxa de O₂ e de CO₂ do submarino, sendo que as regras são as seguintes:

1. Jogue fora os número que não atendem ao critério daquele gás.

2. Se restar apenas 1 número, essa é a taxa daquele gás.

3. Caso contrário, repita o processo com o próximo bit.

E quais são os critérios?

• Para o oxigênio, determinamos o valor mais comum para o bit atual e jogamos fora todos os números que diferem, nessa posição, desse valor. Se 0 e 1 forem igualmente comuns, manter apenas os números com 1 no bit considerado.

• Para gás carbônico, determinamos o valor menos comum para o bit atual e jogamos fora todos os números que diferem, nessa posição, desse valor. Se 0 e 1 forem igualmente comuns, manter apenas os números com 0 no bit considerado.

O primeiro passo da minha solução foi criar uma função que calcula a anti-moda de um vetor. Ela difere da função usada no item anterior somente pelo sinal de subtração, mas isso garante a ela uma propriedade importante: se 0 e 1 empatarem na contagem, ela retorna o valor que vem antes na ordem alfabética, ou seja, 0. Dessa forma a função antimode() realiza exatamente a operação que precisamos para determinar a taxa de gás carbônico.

antimode <- function(x) names(sort(table(x)))[1]

A função abaixo é uma versão recursiva do cálculo das taxas dos gases. A coluna current é só um atalho para deixar o filtro mais enxuto, pois ela não passa da do bit atual. O op(), porém, é a chave que nos permite usar a mesma função para calcular O₂ e CO₂; por padrão a função filtra os valores iguais à anti-moda, mas, com co2 = FALSE, ela filtra os valores diferentes da anti-moda, atendendo ao critério do oxigênio (incluindo o desempate)!

A última linha chama a função de novo para o próximo bit, resolvendo o cálculo.

gas <- function(df, co2 = TRUE, bit = 1) {

  # Condição de parada
  if (bit > 12 || nrow(df) == 1) return(df)

  # Escolher o operador apropriado
  if (co2) op <- `==` else op <- `!=`

  # Filtrar usando antimode() e fazer a recursão
  df |>
    dplyr::mutate(current = .data[[names(df)[bit]]]) |>
    dplyr::filter(op(current, antimode(current))) |>
    dplyr::select(-current) |>
    find_rating(co2 = co2, bit = bit + 1)
}

Só nos resta aplicar essa função na lista de números. Para tentar manter o fim do código em uma pipeline só (já que não foi possível com o resto), eu usei rep_len(list(df), 2) para duplicar a base e poder aplicar gas() e gas(co2 = FALSE) em uma linha só com purrr::map2_dfr(). O final do código deixa cada taxa em uma linha, junta os seu bits, as converte para decimal e multiplica seus valores. Essa é a saída.

"data-raw/03b_binary_diagnostic.txt" |>
  readr::read_table(col_names = "reading") |>
  tidyr::separate(reading, paste0("B", 0:12), "") |>
  dplyr::select(-B0) |>
  list() |>
  rep_len(2) |>
  purrr::map2_dfr(list(gas, \(df) gas(df, FALSE)), ~.y(.x)) |>
  tidyr::unite("reading", dplyr::everything(), sep = "") |>
  dplyr::mutate(reading = strtoi(reading, base = 2)) |>
  dplyr::summarise(output = prod(reading)) |>
  dplyr::pull(output)

Lula Gigante (A)

O quarto dia do AoC foi talvez o mais interessante até agora. Na primeira parte, precisávamos calcular a pontuação da cartela vencedora de um bingo americano: cada cartela é composta por 5 linhas e 5 colunas de números que devem ser riscados conforme eles são anunciados pelo sistema do submarino. A primeira cartela a riscar todos os números de uma linha ou coluna é a vencedora e sua pontuação é a soma de todos os números não riscados multiplicada pelo último número anunciado.

A entrada era composta por uma linha com os números anunciados em sequência e, posteriormente, todas as cartelas da platéia:

# 7,4,9,5,11,17,23,2,0,14,21,24,10,16,13,6,15,25,12,22,18,20,8,19,3,26,1
#
# 22 13 17 11  0
#  8  2 23  4 24
# 21  9 14 16  7
#  6 10  3 18  5
#  1 12 20 15 19
#
#  3 15  0  2 22
#  9 18 13 17  5
# 19  8  7 25 23
# 20 11 10 24  4
# 14 21 16 12  6
#
# 14 21 17 24  4
# 10 16 15  9 19
# 18  8 23 26 20
# 22 11 13  6  5
#  2  0 12  3  7

Eu escolhi um caminho simples para resolver o problema, apesar de o código não ter ficado tão bom assim. Primeiro eu li a sequência de números e criei uma função que transpunha uma matrix numérica e a empilhava com a original.

# Processar os números sorteados
draws <- "data-raw/04a_giant_squid.txt" |>
  readr::read_lines(n_max = 1) |>
  stringr::str_split(",") |>
  purrr::pluck(1) |>
  as.numeric()

# Converter as colunas de uma matrix para linhas e empilhar
cols_to_rows <- function(df) {
  df |>
    dplyr::select(-board, -id) |>
    as.matrix() |>
    t() |>
    tibble::as_tibble(rownames = "id") |>
    purrr::set_names("id", paste0("C", 1:5)) |>
    dplyr::mutate(board = df$board) |>
    dplyr::bind_rows(df) |>
    dplyr::relocate(board, id) |>
    purrr::set_names("id", "board", paste0("N", 1:5))
}

O objetivo de cols_to_rows() era criar uma tabela final com todas as linhas das cartelas e também todas as suas colunas; isso permitiu que eu riscasse os números sorteados aplicando dplyr::na_if() indiscriminadamente. Quando alguma linha da tabela fosse formada somente por NAs (indicando que uma linha ou coluna de alguma cartela estava completa), bastava extrair a cartela original, somar os seus valores não-NA e multiplicar o resultado pelo número sorteado mais recente. A função utilizada para isso se chamava winning_score() e operava recursivamente para poupar tempo.

# Calcular a pontuação da cartela vencedora
winning_score <- function(df, draws) {

  # Marcar o número sorteado com NA (nas linhas e colunas)
  df <- dplyr::mutate(df, dplyr::across(c(N1:N5), dplyr::na_if, draws[1]))

  # Filtrar possíveis linhas/colunas completas
  win <- dplyr::filter(df, dplyr::if_all(c(N1:N5), is.na))

  # Se houver pelo menos uma linha/coluna completa...
  if (nrow(win) > 0) {

    # Extrair a cartela vencedora, somar os não-NA e multiplicar por draws[1]
    output <- df |>
      dplyr::filter(id == win$id, stringr::str_starts(board, "R")) |>
      dplyr::select(-id, -board) |>
      purrr::flatten_dbl() |>
      sum(na.rm = TRUE) |>
      magrittr::multiply_by(draws[1])

    # Retornar a pontuação
    return(output)
  }

  # Recursão para o próximo sorteio
  winning_score(df, draws[-1])
}

# Ler cartelas, empilhas linhas com colunas e riscar usando NAs
"data-raw/04a_giant_squid.txt" |>
  readr::read_table(skip = 1, col_names = paste0("C", 1:5)) |>
  dplyr::mutate(board = (dplyr::row_number() - 1) %/% 5) |>
  dplyr::group_by(board) |>
  dplyr::mutate(id = paste0("R", 1:5)) |>
  dplyr::group_split() |>
  purrr::map_dfr(cols_to_rows) |>
  winning_score(draws)
#> [1] 33348

Lula Gigante (B)

O segundo item do problema pedia o contrário: calcular a pontuação da última cartela a ter uma linha ou coluna completa, ou seja, da cartela perdedora. Na minha solução todo o código permaneceu igual, salvo pela função winning_score(), que virou loosing_score(). A grande novidade é que, quando o programa encontrava uma cartela vencedora, ele verificava se aquela era a última. Se não fosse, ele removia aquela cartela da tabela e, se fosse, ele retornava a pontuação.

# Calcular a pontuação da cartela perdedora
loosing_score <- function(df, draws) {

  # Marcar o número sorteado com NA (nas linhas e colunas)
  df <- dplyr::mutate(df, dplyr::across(c(N1:N5), dplyr::na_if, draws[1]))

  # Filter possible complete rows or cols
  win <- dplyr::filter(df, dplyr::if_all(c(N1:N5), is.na))

  # Se houver pelo menos uma linha/coluna completa...
  if (nrow(win) > 0) {

    # Se restasse apenas uma cartela, calcular a sua pontuação
    if (length(unique(df$id)) == 1) {

      # Extrair a cartela perdedora, somar os não-NA e multiplicar por draws[1]
      output <- df |>
        dplyr::filter(stringr::str_starts(board, "R")) |>
        dplyr::select(-id, -board) |>
        purrr::flatten_dbl() |>
        sum(na.rm = TRUE) |>
        magrittr::multiply_by(draws[1])

      # Retornar a pontuação
      return(output)
    }

    # Jogar fora cartelas que já venceram
    df <- dplyr::filter(df, !id %in% win$id)
  }

  # Recursão para o próximo sorteio
  loosing_score(df, draws[-1])
}

Aventura Hidrotermal (A)

O quinto dia do AoC foi um pouco mais tranquilo do que o anterior porque eu tive ajuda da incrível Renata Hirota. Hoje tínhamos as coordenadas cartesianas do início e do fim de tubulações submarinas e o objetivo era descobrir quantos pontos do plano tinham mais de uma tubulação passando por eles. No primeiro item deveríamos considerar apenas as tubulações verticais e horizontais.

• Uma entrada do tipo 1,1 -> 1,3 cobria os pontos 1,1, 1,2 e 1,3.

• Uma entrada do tipo 9,7 -> 7,7 cobria os pontos 9,7, 8,7 e 7,7.

A minha ideia começava filtrando os pontos em que x1 == x2 ou y1 == y2 e expandindo as coordenadas para criar uma lista que contivesse todos os pontos pelos quais as tubulações passavam. Eu resolvi isso com o paste(x1:x2, y1:y2), pois a paste() repetiria a coordenada que não muda ao longo da coordenada que muda: paste(9:7, 7:7) := "9 7" "8 7" "7 7".

Depois disso bastava contar o números de ocorrências de cada ponto do plano, filtrar aqueles que ocorriam mais de 1 vez e contar quantos pontos restavam. Esta era a saída do problema.

"data-raw/05a_hydrothermal_venture.txt" |>
  readr::read_csv(col_names = c("x1", "y1x2", "y2")) |>
  tidyr::separate(sep = " -> ", col = "y1x2", into = c("y1", "x2")) |>
  dplyr::filter(x1 == x2 | y1 == y2) |>
  dplyr::mutate(
    dif_x = purrr::map2(x1, x2, seq),
    dif_y = purrr::map2(y1, y2, seq),
    coord = purrr::map2(dif_x, dif_y, paste)
  ) |>
  tidyr::unnest(coord) |>
  dplyr::count(coord) |>
  dplyr::filter(n > 1) |>
  nrow()
#> [1] 7142

Aventura Hidrotermal (B)

O segundo item parecia bastante mais complexo, pois agora deveríamos considerar todas as tubulações da entrada, removendo o dplyr::filter() do item anterior. Mas uma especificação do enunciado facilitou tudo: todas as linhas diagonais tinham inclinação de 45 graus.

• Uma entrada do tipo 1,1 -> 3,3 cobria os pontos 1,1, 2,2 e 3,3.

• Uma entrada do tipo 9,7 -> 7,9 cobria os pontos 9,7, 8,8 e 7,9.

Isso significa que a estratégia do paste() continuava funcionando! Note que paste(1:3, 1:3) := "1 1" "2 2" "3 3", então bastou tirar o dplyr::filter() que a solução estava pronta.

"data-raw/05b_hydrothermal_venture.txt" |>
  readr::read_csv(col_names = c("x1", "y1x2", "y2")) |>
  tidyr::separate(sep = " -> ", col = "y1x2", into = c("y1", "x2")) |>
  dplyr::mutate(
    dif_x = purrr::map2(x1, x2, seq),
    dif_y = purrr::map2(y1, y2, seq),
    coord = purrr::map2(dif_x, dif_y, paste)
  ) |>
  tidyr::unnest(coord) |>
  dplyr::count(coord) |>
  dplyr::filter(n > 1) |>
  nrow()
#> [1] 20012

Peixes-lanterna (A)

O dia 6 do AoC me pegou um pouco de surpresa. O primeiro item foi tranquilo de fazer: a entrada era uma lista de números que representavam os “contadores biológicos” de um cardume de peixes-lanterna e precisávamos retornar o número de peixes depois de 80 dias.

Os peixes adultos demoram 7 dias (contador vai de 6 até 0) para gerar um novo peixe bebê e um peixe bebê demora 9 dias (contador vai de 8 até 0) para gerar seu primeiro filhote.

Estado inicial   : 3,4,3,1,2
Depois de  1 dia : 2,3,2,0,1
Depois de  2 dias: 1,2,1,6,0,8
Depois de  3 dias: 0,1,0,5,6,7,8
Depois de  4 dias: 6,0,6,4,5,6,7,8,8
Depois de  5 dias: 5,6,5,3,4,5,6,7,7,8
Depois de  6 dias: 4,5,4,2,3,4,5,6,6,7
Depois de  7 dias: 3,4,3,1,2,3,4,5,5,6
Depois de  8 dias: 2,3,2,0,1,2,3,4,4,5
Depois de  9 dias: 1,2,1,6,0,1,2,3,3,4,8
Depois de 10 dias: 0,1,0,5,6,0,1,2,2,3,7,8
Depois de 11 dias: 6,0,6,4,5,6,0,1,1,2,6,7,8,8,8
Depois de 12 dias: 5,6,5,3,4,5,6,0,0,1,5,6,7,7,7,8,8
Depois de 13 dias: 4,5,4,2,3,4,5,6,6,0,4,5,6,6,6,7,7,8,8
Depois de 14 dias: 3,4,3,1,2,3,4,5,5,6,3,4,5,5,5,6,6,7,7,8
Depois de 15 dias: 2,3,2,0,1,2,3,4,4,5,2,3,4,4,4,5,5,6,6,7
Depois de 16 dias: 1,2,1,6,0,1,2,3,3,4,1,2,3,3,3,4,4,5,5,6,8
Depois de 17 dias: 0,1,0,5,6,0,1,2,2,3,0,1,2,2,2,3,3,4,4,5,7,8
Depois de 18 dias: 6,0,6,4,5,6,0,1,1,2,6,0,1,1,1,2,2,3,3,4,6,7,8,8,8,8

O meu código até que ficou bem simples. Precisei apenas de uma função que, todo dia, subtraia 1 de todos os contadores, criava 1 peixe com contador 8 para cada peixe com contador -1 e, por fim, subia todos os peixes com contador -1 para 6.

# Rodar n cíclos de reprodução do peixe-lanterna
reproduce <- function(fish, n = 80) {

  # Condição de parada
  if (n == 0) return(length(fish))

  # Reduzir contadores biológicos
  fish <- fish - 1L

  # Criar novos peixes e reiniciar contadores
  fish <- append(fish, rep_len(8L, length(fish[fish == -1L])))
  fish[fish == -1L] <- 6L

  # Recursão
  reproduce(fish, n = n - 1)
}

# Ler uma lista de peixes e reproduzir por 80 dias
"data-raw/06a_lanternfish.txt" |>
  readr::read_lines() |>
  stringr::str_split(",") |>
  purrr::pluck(1) |>
  as.integer() |>
  reproduce()
#> [1] 362666

Peixes-lanterna (B)

O segundo item do exercício não mudava essencialmente nada em relação ao primeiro. Assumindo espaço e recursos infinitos, quantos peixes teríamos depois de 256 dias?

Para resolver esse item, em teoria, seria necessário trocar apenas o valor do n por 256. Mas não foi o que aconteceu… Por causa da ineficiência do algoritmo, obter uma resposta demoraria horas e acabaria com a memória do meu computador. Foi necessário pensar em um novo método de resolver o problema.

A solução abaixo foi inspirada pela função table(). Para reduzir a exigência de espaço e não precisar iterar ao longo de um vetor com todos os peixes, eu agrupei os peixes com o mesmo contador biológico em apenas uma linha de uma tabela! Assim o programa nunca precisava lidar com mais de 9 linhas por dia, resolvendo as complicações com espaço e tempo.

# Rodar n cíclos de reprodução do peixe-lanterna
reproduce <- function(fish, n = 80) {

  # Condição de parada
  if (n == 0) return(sum(fish$n))

  # Reduzir contadores biológicos
  fish <- dplyr::mutate(fish, timer = timer - 1L)

  # Criar novos peixes
  babies <- fish |>
    dplyr::filter(timer == -1L) |>
    dplyr::mutate(timer = 8L)

  # Reiniciar contadores e recursão
  fish |>
    dplyr::bind_rows(babies) |>
    dplyr::mutate(timer = ifelse(timer == -1L, 6L, timer)) |>
    dplyr::group_by(timer) |>
    dplyr::summarise(n = sum(n)) |>
    reproduce(n = n - 1)
}

# Ler uma lista de peixes e reproduzir por 256 dias
"data-raw/06b_lanternfish.txt" |>
  readr::read_lines() |>
  stringr::str_split(",") |>
  purrr::pluck(1) |>
  as.integer() |>
  tibble::as_tibble() |>
  purrr::set_names("timer") |>
  dplyr::count(timer) |>
  reproduce(n = 256) |>
  format(scientific = FALSE)
#> [1] 1640526601595

A Traição das Baleias (A)

O dia 7 do AoC foi o mais rápido até agora. A nossa tarefa era determinar a posição horizontal na qual um exército de caranguejos deveria se alinhar, com a restrição de que deveríamos encontrar a posição que exigisse menos combustível.

Cada caranguejo estava equipado de um mini-submarino que gastava 1 unidade de combustível por unidade de deslocamento, logo o total de combustível gasto pela tropa para ir até a posição x seria simplesmente sum(abs(positions - x)). A saída era o combustível gasto para levar todos os caranguejos até a posição mais econômica.

# Ler vetor de posições iniciais
positions <- "data-raw/07a_the_treachery_of_whales.txt" |>
  readr::read_lines() |>
  stringr::str_split(",") |>
  purrr::pluck(1) |>
  as.integer()

# Iterar nas posições para encontrar a mais barata
cheapest <- Inf
for (pos in max(positions):min(positions)) {

  # Calcular o combustível gasto para a posição
  fuel <- sum(abs(positions - pos))

  # Trocar a resposta se essa posição for mais econômica
  if (fuel < cheapest) cheapest <- fuel
}

# Imprimir
cheapest
#> [1] 328318

Note que não era necessário testar nenhuma posição fora do intervalo max(positions):min(positions)! Qualquer posição fora disso seria menos econômica do que a ponta mais próxima a ela dentro do intervalo.

A Traição das Baleias (B)

O segundo item mantinha o mesmo problema, mas mudava o cálculo do gasto de combustível dos mini-submarinos: o primeiro movimento consumiria 1 unidade de combustível, o segundo consumiria 2 unidades, o terceiro consumiria 3 e assim por diante.

A única linha que muda dessa solução para a anterior é a que calcula o gasto de combustível para cada posição. Se um caranguejo estiver na posição a e quiser ir até a x, o seu consumo total será ${\sum }_{k=0}^{|a-x|}k$ . Abaixo a operação sum(purrr::map_int(positions, ~sum(0:abs(.x - pos)))) faz isso para todos os caranguejos.

# Iterar nas posições para encontrar a mais barata
cheapest <- Inf
for (pos in max(positions):min(positions)) {

  # Calcular o combustível gasto para a posição
  fuel <- sum(purrr::map_int(positions, ~sum(0:abs(.x - pos))))

  # Trocar a resposta se essa posição for mais econômica
  if (fuel < cheapest) cheapest <- fuel
}

# Imprimir
cheapest
#> [1] 328318

Busca em Sete Segmentos (A)

O oitavo dia do AoC foi bastante difícil para mim. O problema começou pelo enunciado, que é longo e complexo, então realmente recomendo ler a versão original além do resumo que trago abaixo.

Dito isso, vamos lá. O problema dizia respeito a displays de sete segmentos, onde cada número é representado por um conjunto de segmentos acessos; de acordo com o diagrama abaixo, vemos que 0 é representado por abcefg, 1 é cf e assim por diante.

#   0:      1:      2:      3:      4:
#  aaaa    ....    aaaa    aaaa    ....
# b    c  .    c  .    c  .    c  b    c
# b    c  .    c  .    c  .    c  b    c
#  ....    ....    dddd    dddd    dddd
# e    f  .    f  e    .  .    f  .    f
# e    f  .    f  e    .  .    f  .    f
#  gggg    ....    gggg    gggg    ....

#   5:      6:      7:      8:      9:
#  aaaa    aaaa    aaaa    aaaa    aaaa
# b    .  b    .  .    c  b    c  b    c
# b    .  b    .  .    c  b    c  b    c
#  dddd    dddd    ....    dddd    dddd
# .    f  e    f  .    f  e    f  .    f
# .    f  e    f  .    f  e    f  .    f
#  gggg    gggg    ....    gggg    gggg

O desafio é que, no nosso submarino, todo os displays estão com os fios trocados e, para piorar, cada display tem um arranjo diferente. A entrada do problema é uma série de linhas como a abaixo: como os 10 dígitos são representados em um display específico (em qualquer ordem) e, depois da barra, 4 dígitos que precisamos decodificar.

# acedgfb cdfbe gcdfa fbcad dab cefabd cdfgeb eafb cagedb ab |
# cdfeb fcadb cdfeb cdbaf

Alguns dígitos são fáceis de identificar. Os números 1, 4, 7 e 8 usam números únicos de segmentos, então é possível perceber que, quando ab acenderam, o display estava tentando mostrar um 1. Seguindo a mesma lógica, dab é 7, eafb é 4 e acedgfb é 8.

O objetivo do primeiro item do dia 08 era contar quantas vezes os dígitos 1, 4, 7 e 8 aparecem nas saídas que devemos decodificar (lado direito da barra). A solução foi bem simples, pois bastou pivotar a tabela e filtrar as linhas que tinham stringr::str_length() igual a 2, 3, 4, ou 7.

"data-raw/08a_seven_segment_search.txt" |>
  readr::read_delim(" ", col_names = NULL) |>
  purrr::set_names(
    paste0("P", stringr::str_pad(1:10, 2, "left", "0")), "remove",
    paste0("V", stringr::str_pad(1:4, 2, "left", "0"))
  ) |>
  dplyr::select(-remove) |>
  dplyr::select(V01:V04) |>
  tidyr::pivot_longer(V01:V04, names_to = "col", values_to = "value") |>
  dplyr::filter(stringr::str_length(value) %in% c(2, 4, 3, 7)) |>
  nrow()
#> [1] 365

Busca em Sete Segmentos (B)

O verdadeiro problema veio no item 2. Aqui o exercício abandona qualquer pretexto de bondade e pede de uma vez para decodificarmos os dígitos depois da barra baseados nos 10 padrões antes da barra. A saída deveria ser a soma de todos os números de 4 dígitos decodificados.

Minha primeira tentativa de resolver o problema testava cada segmento em cada posição (essencialmente verificando todos os possíveis jeitos de embaralhar os fios) para ver em qual das configurações os padrões faziam sentido; depois seria só bater os padrões com os 4 dígitos da direita para ver quem é quem. Não preciso nem dizer que isso seria demorado demais para funcionar.

Depois de um tempo olhando para o arquivo de entrada, entretanto, me veio uma luz: talvez eu pudesse analisar a frequência com a qual cada segmento aparece nos padrões. Perceba, por exemplo, que no diagrama acima o segmento e está ligado em 4 dígitos (0, 2, 6 e 8). O fato importante é que ele é o único segmento com essa propriedade!

Partindo deste princípio, criei as seguinte regras para o código:

1. O único segmento que aparecer 4 vezes nos padrões corresponderá ao e;

2. O único segmento que aparecer 6 vezes nos padrões corresponderá ao b;

3. O único segmento que aparecer 9 vezes nos padrões corresponderá ao f;

4. No padrão com 2 segmentos acessos, aquele que não representar o e corresponderá ao c (número 1).

5. No padrão com 3 segmentos acessos, aquele que não representar c ou f corresponderá ao a (número 7).

6. No padrão com 4 segmentos acessos, aquele que não representar b, c ou f corresponderá ao d (número 4).

7. O segmento que ainda não tiver correspondente corresponderá ao g.

O resto do código cuidava de organizar as letras de cada dígito de modo que fosse fácil transpor as correspondências dos 10 padrões para os 4 valores das saídas.

# Decodificar uma linha da entrada
decode <- function(entry) {

  # Encontra e quebra o padrão que tenha certa str_length()
  find_by_len <- function(patterns, len) {
    patterns |>
      magrittr::extract(stringr::str_length(patterns) == len) |>
      stringr::str_split("") |>
      purrr::pluck(1)
  }

  # Frequências de referência
  ref_freq <- list(
    "a" = 8,
    "b" = 6,
    "c" = 8,
    "d" = 7,
    "e" = 4,
    "f" = 9,
    "g" = 7
  )

  # Valores de referência
  ref_val <- list(
    "abdefg" = 6,
    "abcefg" = 0,
    "cf" = 1,
    "acdfg" = 3,
    "abcdfg" = 9,
    "abcdefg" = 8,
    "bcdf" = 4,
    "acf" = 7,
    "abdfg" = 5,
    "acdeg" = 2
  )

  # Calcular frequências desta entrada
  cur_freq <- entry |>
    dplyr::select(P01:P10) |>
    purrr::flatten_chr() |>
    stringr::str_split("") |>
    purrr::flatten_chr() |>
    table()

  # Criar um dicionário para traduzir os segmentos
  dict <- list()

  # Traduzir segmentos com frequências únicas
  dict[["e"]] <- names(cur_freq[cur_freq == 4])
  dict[["b"]] <- names(cur_freq[cur_freq == 6])
  dict[["f"]] <- names(cur_freq[cur_freq == 9])

  # Extrair padrões da entrada
  patterns <- entry |>
    dplyr::select(P01:P10) |>
    purrr::flatten_chr()

  # Determinar segmento que falta do 1
  one <- find_by_len(patterns, 2)
  dict[["c"]] <- one[!one %in% purrr::flatten_chr(dict)]

  # Determinar segmento que falta do 7
  seven <- find_by_len(patterns, 3)
  dict[["a"]] <- seven[!seven %in% purrr::flatten_chr(dict)]

  # Determinar segmento que falta do 4
  four <- find_by_len(patterns, 4)
  dict[["d"]] <- four[!four %in% purrr::flatten_chr(dict)]

  # Determinar último segmento que falta
  dict[["g"]] <- names(cur_freq)[!names(cur_freq) %in% purrr::flatten_chr(dict)]

  # Traduzir segmentos dos valores de saída
  entry |>
    dplyr::select(V01:V04) |>
    purrr::flatten_chr() |>
    stringr::str_split("") |>
    purrr::map(~names(dict)[match(.x, dict)]) |>
    purrr::map(sort) |>
    purrr::map(stringr::str_c, collapse = "") |>
    purrr::map(~purrr::flatten_chr(ref_val)[match(.x, names(ref_val))]) |>
    purrr::flatten_chr() |>
    as.integer() |>
    stringr::str_c(collapse = "") |>
    as.numeric()
}

# Ler entrada, mapear decode() e somar todas os valores de saída
"data-raw/08b_seven_segment_search.txt" |>
  readr::read_delim(" ", col_names = NULL) |>
  purrr::set_names(
    paste0("P", stringr::str_pad(1:10, 2, "left", "0")), "remove",
    paste0("V", stringr::str_pad(1:4, 2, "left", "0"))
  ) |>
  dplyr::select(-remove) |>
  tibble::rowid_to_column("id") |>
  tidyr::nest(entry = c(P01:V04)) |>
  dplyr::mutate(output = purrr::map_dbl(entry, decode)) |>
  dplyr::summarise(output = sum(output)) |>
  dplyr::pull(output)
#> [1] 975706

Bacia de Fumaça (A)

O dia 9 do AoC foi desafiador, apesar de não tanto quanto o anterior. Como sempre o problema envolvia uma historinha que não contribui muito para o entendimento do enunciado, então vamos direto ao ponto: recebemos uma matriz 100x100 que representa um mapa de alturas e precisávamos encontrar todos os pontos que eram cercados (em cima, embaixo, na esquerda e na direita) por pontos mais altos. Ademais sabíamos que as alturas iam de 0 a 9 e que as fronteiras fora do mapa podiam ser todas consideradas mais altas que o resto do mapa. A resposta do problema seria o risco total de todos os pontos baixos, onde o risco de um ponto é igual à sua altura + 1.

O problema não é tão complicado, pois bastaria iterar em todos os pontos da matriz e comparar cada um com seus vizinhos. O maior dezafio era lidar com as fronteiras do mapa. Para isso, resolvi cercar toda a matriz por noves e iterar no quadrado 2:101x2:101.

# Ler o mapa de alturas e estofar as fronteiras com 9
height <- "data-raw/09a_smoke_basin.txt" |>
  readr::read_lines() |>
  stringr::str_split("") |>
  purrr::flatten_chr() |>
  as.integer() |>
  matrix(nrow = 100, ncol = 100, byrow = TRUE) |>
  rbind(rep(9, 100)) |>
  {\(m) rbind(rep(9, 100), m)}() |>
  cbind(rep(9, 102)) |>
  {\(m) cbind(rep(9, 102), m)}()

# Iterar por todos os pontos
risk <- 0
for (i in 2:101) {
  for (j in 2:101) {

    # Verificar se é um ponto baixo e somar o risco ao total
    if (
      height[i, j] < height[i - 1, j] &&
      height[i, j] < height[i + 1, j] &&
      height[i, j] < height[i, j - 1] &&
      height[i, j] < height[i, j + 1]
    ) {
      risk <- risk + height[i, j] + 1
    }
  }
}

# Imprimir
risk
#> [1] 494

Bacia de Fumaça (B)

O segundo item já era mais complicado. Considerando que os pontos com altura 9 não pertencem a nenhuma bacia, precisávamos encontrar as 3 maiores bacias no nosso mapa. Uma bacia é definida por toda uma região cercada por noves e seu tamanho é igual ao número de pontos contíguos contidos nessa área.

O diagrama abaixo não estava no enunciado, mas ele me ajudou muito a entender o que era uma bacia. Para criá-lo, eu peguei um retângulo na ponta do meu mapa e substituí todos os números menores que 9 por um ., representando assim as bacias. Cada região cercada por noves é uma bacia diferente.

# ....999.........9.9....99......9....9..........9
# ...9.9.9.......9...9..9.......9.9...99.99.9.....
# ..9.....9.9.....9...99...........999.999.9.9....
# ..9......9.9...9....999.........9..9..9.....999.
# 99..........999......9999......9..9..9.....9...9
# ...........9..9........99...9.9.......9.........
# 9..............9...9..9..9.99.9......9..........
# ...........99.9...9.99....9..99.....9...........
# ............99....9..9.......9.......9..........
# 9........99999...9....9.9....9.......999........

Minha solução começou igual à do item anterior, mas desta vez criei também uma tabela com todos os pontos do mapa. Meu objetivo era fazer uma busca em largura e remover desta tabela os pontos já explorados.

# Criar uma tabela de pontos a explorar
points <- purrr::cross2(2:101, 2:101) |>
  purrr::map(purrr::flatten_int) |>
  purrr::transpose() |>
  purrr::set_names("i", "j") |>
  tibble::as_tibble() |>
  tidyr::unnest(c(i, j))

A seguir eu criei uma função que explorava uma bacia a partir de um ponto “semente”. O primeiro passo era verificar se o ponto já tinha sido explorado e retornar 0 se sim (indicando que aquele ponto não contribuiria mais para o tamanho da bacia). Se o ponto não tivesse sido explorado, então o código o removia da tabela de pontos e verificava se ele tinha altura 9, mais uma vez retornando 0 se sim. O final da função aplicava uma recursão nos 4 vizinhos do ponto, somando os tamanhos das 4 sub-bacias encontradas mais 1 (indicando que o ponto “semente” contribuia em 1 para o tamanho total da bacia).

# Explorar uma bacia
explore <- function(a, b) {

  # Pular se o ponto já tiver sido explorado
  if (nrow(dplyr::filter(points, i == a, j == b)) == 0) return(0)

  # Marcar o ponto como explorado
  points <<- dplyr::filter(points, i != a | j != b)

  # Se a altura for 9, então ele não faz parte da bacia
  if (height[a, b] == 9) return(0)

  # Adicionar os pontos vizinhos à bacia
  return(
    explore(a - 1, b) +
    explore(a + 1, b) +
    explore(a, b - 1) +
    explore(a, b + 1) + 1
  )
}

A resposta para o item era o produto dos tamanhos das 3 maiores bacias do mapa, então o programa terminava iterando na matriz, calculando o tamanho de todas as bacias e seguindo para obter o resultado final.

# Iterar por todos os pontos
basins <- matrix(rep(0, 10404), 102, 102)
for (i in 2:101) {
  for (j in 2:101) {
    basins[i, j] <- explore(i, j)
  }
}

# Multiplicar as 3 maiores bacias
basins |>
  sort(decreasing = TRUE) |>
  magrittr::extract(1:3) |>
  prod()
#> [1] 1048128

Pontuação de Sintaxe (A)

O dia 10 do AoC pedia para que resolvessemos um clássico problema de parentização com alguns facilitadores. Em resumo, recebíamos uma string composta por parênteses e seus amigos ("(", “[”, “{”, “<”, “>”, “}”, “]”, “)”) e precisávamos identificar se o fechamento de algum deles estava errado, por exemplo, “[}”, “{()()()>”, etc. Para cada string que tivesse um fechamento ilegal recebia uma quantidade de pontos de acordo com a tabela abaixo e, finalmente, a saída do exercício era a soma de todas as pontuações.

# ): 3 pontos.
# ]: 57 pontos.
# }: 1197 pontos.
# >: 25137 pontos.

Para quem nunca viu um problema desse tipo, a solução pode ser alcançada facilmente usando uma pilha. Cada caractere que abre um bloco é colocado na pilha e, para cada caractere que fecha um bloco, removemos o elemento do topo da pilha. Se os caracteres se complementam corretamente o algoritmo segue em frente, caso contrário ele busca a pontuação na tabela e retorna.

# Correspondência de valores
scores <- list(
  ")" = 3,
  "]" = 57,
  "}" = 1197,
  ">" = 25137
)

# Calcular a pontuação por caractere ilegal em uma linha
score_ilegal <- function(line) {
  stack <- flifo::lifo()

  # Iterar na linha até um elemento não corresponder
  symbols <- stringr::str_split(line, "")[[1]]
  for (symbol in symbols) {

    # Empilhar ou desempilhar (e calcular pontuação se necessário)
    if (symbol %in% c("(", "[", "{", "<")) {
      flifo::push(stack, symbol)
    } else {
      check <- flifo::pop(stack)
      if (
        (check == "{" && symbol != "}") ||
        (check == "(" && symbol != ")") ||
        (check == "[" && symbol != "]") ||
        (check == "<" && symbol != ">")
      ) {
        return(scores[names(scores) == symbol][[1]])
      }
    }
  }

  return(0)
}

# Iterar nas linhas e calcular pontuações
"data-raw/10a_syntax_scoring.txt" |>
  readr::read_lines() |>
  purrr::map_dbl(score_ilegal) |>
  sum()
#> [1] 216297

Pontuação de Sintaxe (B)

O segundo item do problema pedia para que começássemos removendo as linhas que tinham pontuação maior que 0 (então só foi necessário filtrar isso no código, que vou omitir). Depois disso o objetivo era completar as linhas que restavam.

O fato é que as linhas restantes estavam todas com um pedaço faltando, por exemplo, “[({(<(())[]>[[{[]{<()<»” precisa ainda de “}}]])})]” para ficar correta. Usando a lógica do item anterior, só precisávamos seguir o mesmo roteiro e, ao final da linha, contar os pontos dos caracteres que ainda haviam sobrado na pilha.

Desta vez a regra de pontuação era diferente: para cada caractere faltante, precisávamos multiplicar a pontuação corrente por 5 e então somar o valor do caractere de acordo com uma nova tabelha. A resposta final era a mediana da pontuação de todoas as linhas. Enfim, o código vai a seguir:

# Ler linhas e remover corrompidas
lines <- readr::read_lines("data-raw/10b_syntax_scoring.txt")
lines <- lines[purrr::map_dbl(lines, score_ilegal) == 0]

# Correspondência de valores
scores <- list(
  "(" = 1,
  "[" = 2,
  "{" = 3,
  "<" = 4
)

# Calcular a pontuação por caractere faltante em uma linha
score_complete <- function(line) {
  stack <- flifo::lifo()

  # Iterar na linha e remover parte completa
  symbols <- stringr::str_split(line, "")[[1]]
  for (symbol in symbols) {

    # Empilhar ou desempilhar
    if (symbol %in% c("(", "[", "{", "<")) {
      flifo::push(stack, symbol)
    } else {
      flifo::pop(stack)
    }
  }

  # Iterar no resto da pilha e calcular pontos
  score <- 0
  while (flifo::size(stack) > 0) {
    check <- flifo::pop(stack)
    score <- (score * 5) + scores[names(scores) == check][[1]]
  }

  return(score)
}

# Pegar mediana das pontuações
lines |>
  purrr::map_dbl(score_complete) |>
  median()
#> [1] 2165057169

Polvo-dumbo (A)

O dia 11 do AoC foi bastante complicado e o meu código talvez tenha ficado pior ainda. As instruções eram até simples: recebemos uma matriz 10x10 com os níveis de energia de 100 polvos-dumbo e precisávamos acompanhar seus níveis de energia ao longo de 100 iterações. As regras eram as seguintes:

• Primeiro, o nível de energia de cada polvo sobe em 1.

• Depois, qualquer polvo com nível de energia maior que 9 emite luz (pisca). Isso aumenta o nível de energia de todos os polvos adjacentes em 1, incluindo os adjacentes diagonalmente. Se isso causar um polvo a atingir um nível de energia maior que 9, ele também pisca. Esse processo continua conforme mais polvos passam do nível de energia 9. Um polvo só pode piscar uma vez por passo e não pode subir mais nenhum nível de energia a partir daí.

• Finalmente, todos os polvos que piscaram durante este passo têm seus níveis de energia ajustados para 0 (já que ele usou toda a sua energia para piscar).

Meu código seguia esse procedimento à risca e precisou de 3 loops aninhados para funcionar. O truque mais importante foi criar um clone dos polvos que marcava todos os polvos que já tinham piscado para garantir que nenhum deles ganharia mais energia durante aquele passo; este mecanismo envolvia marcar um polvo que piscava com 0 e um polvo que tinha piscado em qualquer ponto anterior do loop com -1 (para que ele não fosse contado duas vezes). O resultado final deveria ser o número de piscadas totais depois dos 100 passos.

# Ler matriz
dumbo <- "data-raw/11a_dumbo_octopus.txt" |>
  readr::read_table(col_names = FALSE) |>
  tidyr::separate(X1, paste0("C", 0:10), "") |>
  dplyr::select(-C0) |>
  dplyr::mutate_all(as.numeric) |>
  as.matrix()

# Iterar nos 100 passos
flashes <- 0
for (k in 1:100) {

  # Aumentar níveis de energia
  dumbo <- (dumbo + 1) %% 10

  # Adicionar energia aos polvos cujos vizinhos piscaram
  flag <- FALSE
  while(!flag) {

    # Contar piscadas
    flashes <- flashes + sum(dumbo == 0)

    # Adicionar energia aos polvos adjacentes a piscadas
    dumbo_ <- dumbo
    for (i in 1:10) {
      for (j in 1:10) {

        # Índices dos vizinhos
        i1 <- i - 1
        i2 <- min(i + 1, 10)
        j1 <- j - 1
        j2 <- min(j + 1, 10)

        # Adicionar energia nos índices (exceto no centro)
        if (dumbo[i, j] == 0) {
          dumbo_[i1:i2, j1:j2] <- dumbo_[i1:i2, j1:j2] + 1
          dumbo_[i, j] <- dumbo_[i, j] - 1
        }
      }
    }

    # Separar piscadas anteriores dos que piscaram na última iteração
    dumbo <- ifelse(dumbo == -1, 0, dumbo)

    # Sobrescrever as piscadas com 0 (eles não podem receber mais energia)
    dumbo <- ifelse(dumbo == 0, 0, dumbo_)

    # Verificar se o passo atual acabou
    if (!any(dumbo > 9)) {
      flag <- TRUE
    } else {

      # Prevenir piscadas antigas de serem contadas de novo
      dumbo <- ifelse(dumbo == 0, -1, dumbo)
      dumbo <- ifelse(dumbo > 9, 0, dumbo)
    }
  }
}

# Imprimir
flashes
#> [1] 1681

Polvo-dumbo (B)

Felizmente o segundo item o exercício de hoje foi bem mais simples. Eventualmente todos os polvos entram em sincronia, ou seja, passam a piscar todos juntos; o nosso objetivo era descobrir em que passo isso acontecia. A única coisa que precisei fazer com o código do item anterior foi ignorar o limite de passos e criar uma verificação para quando todos os polvos atingiam 0 de energia juntos.

# Ler matriz
dumbo <- "data-raw/11b_dumbo_octopus.txt" |>
  readr::read_table(col_names = FALSE) |>
  tidyr::separate(X1, paste0("C", 0:10), "") |>
  dplyr::select(-C0) |>
  dplyr::mutate_all(as.numeric) |>
  as.matrix()

# Iterar em 1000 passos
for (k in 1:1000) {
  print(k)

  # Aumentar níveis de energia
  dumbo <- (dumbo + 1) %% 10

  # Adicionar energia aos polvos cujos vizinhos piscaram
  flag <- FALSE
  while(!flag) {

    # Adicionar energia aos polvos adjacentes a piscadas
    dumbo_ <- dumbo
    for (i in 1:10) {
      for (j in 1:10) {

        # Índices dos vizinhos
        i1 <- i - 1
        i2 <- min(i + 1, 10)
        j1 <- j - 1
        j2 <- min(j + 1, 10)

        # Adicionar energia nos índices (exceto no centro)
        if (dumbo[i, j] == 0) {
          dumbo_[i1:i2, j1:j2] <- dumbo_[i1:i2, j1:j2] + 1
          dumbo_[i, j] <- dumbo_[i, j] - 1
        }
      }
    }

    # Separar piscadas anteriores dos que piscaram na última iteração
    dumbo <- ifelse(dumbo == -1, 0, dumbo)

    # Sobrescrever as piscadas com 0 (eles não podem receber mais energia)
    dumbo <- ifelse(dumbo == 0, 0, dumbo_)

    # Verificar se o passo atual acabou
    if (!any(dumbo > 9)) {
      flag <- TRUE
    } else {

      # Prevenir piscadas antigas de serem contadas de novo
      dumbo <- ifelse(dumbo == 0, -1, dumbo)
      dumbo <- ifelse(dumbo > 9, 0, dumbo)
    }
  }

  # Parar se todos os polvos tiverem piscado
  if (all(dumbo %in% c(0, -1))) {
    break()
  }
}

# Imprimir
k
#> [1] 276