Day 11: Plutonian Pebbles
Megathread guidelines
- Keep top level comments as only solutions, if you want to say something other than a solution put it in a new post. (replies to comments can be whatever)
- You can send code in code blocks by using three backticks, the code, and then three backticks or use something such as https://topaz.github.io/paste/ if you prefer sending it through a URL
FAQ
- What is this?: Here is a post with a large amount of details: https://programming.dev/post/6637268
- Where do I participate?: https://adventofcode.com/
- Is there a leaderboard for the community?: We have a programming.dev leaderboard with the info on how to join in this post: https://programming.dev/post/6631465
Zee
Zee is my Dutch dialect of C. Since Dutch has compound words, so does Zee: “const char **” becomes vasteletterverwijzingsverwijzing, not vaste letter verwijzing verwijzing, which would be incorrect. A pointer to a long long unsigned int is, obviously, a zeergrootnatuurlijkgetalverwijzing.
Code
#ingesloten "zee.kop"
#ingesloten "algemeen.kop"
besloten getal
splits(
zeer groot natuurlijk getal x,
zeergrootnatuurlijkgetalverwijzing a,
zeergrootnatuurlijkgetalverwijzing b)
{
zeer groot natuurlijk getal m;
getal n, g;
mits (!x) lever 0;
voor (n=0, m=1; m<=x; n++, m*=10) ; mits (n%2) lever 0;
voor (g=0, m=1; g<n/2; g++, m*=10) ;
volg a = x/m;
volg b = x%m; lever 1;
}
#definieer GEHL (1024*1024)
besloten zeer groot natuurlijk getal geh[GEHL][76];
besloten zeer groot natuurlijk getal
afdalen(zeer groot natuurlijk getal w, getal n)
{
zeer groot natuurlijk getal a,b;
mits (n<1 ) lever 1;
mits (w==0) lever afdalen(1, n-1);
mits (w<10) lever afdalen(w*2024, n-1);
mits (w<GEHL && geh[w][n]) lever geh[w][n];
mits (!splits(w, naar a, naar b)) lever afdalen(w*2024, n-1);
lever w<GEHL ? geh[w][n] =
afdalen(a, n-1) + afdalen(b, n-1) :
afdalen(a, n-1) + afdalen(b, n-1);
}
getal
aanvang(getal parametersom, vasteletterverwijzingsverwijzing parameters)
{
zeer groot natuurlijk getal d1=0,d2=0, waarde;
mits (parametersom > 1)
VERWERP(heropen(parameters[1], "r", standaardinvoer));
zolang (invorm(" %llu", &waarde) == 1) {
d1 += afdalen(waarde, 25);
d2 += afdalen(waarde, 75);
}
uitvorm("11: %llu %llu\n", d1, d2);
lever 0;
}
And of course we don’t have a Makefile but a Maakbestand:
alles: €{DAGEN}
schoon:
€{WIS} -f €{DAGEN} *.o
...
.TWIJFELACHTIG: alles schoon oplossingen
.UITGANGEN: .zee .o
.zee.o:
€{ZEE} €{VOORWERKVLAG} €{ZEEVLAG} -o €@ -c €<
Yet more proof that the dutch are mad :D
Is it your own esolang, or is it commonly used by dutch speakers?
No it’s just me messing about with macros (but it does work!)
I do want to explore the type naming rules, see if I can write a parser for it. The C rules are funky by themselves but this is another level. “vaste letterverwijzing” is “char * const” but “vasteletterverwijzing” (without the space) is “const char *”. Then there’s grammatical gender: “vast getal” (const int) but “vaste letter” (const char)
Uiua
I thought this was going to be trivial to implement in Uiua, but I managed to blow the stack, meaning I had to set an environment variable in order to get it to run. That doesn’t work in Uiua Pad, so for any counts larger than 15 you need to run it locally. Built-in memoisation though so that’s nice.
# NB Needs env var UIUA_RECURSION_LIMIT=300
Next ← ⍣([1] °0|[×2024] °1◿2⧻°⋕.|⍜°⋕(↯2_∞))
Count ← |2 memo(⨬(1|/+≡Count¤-1⊙Next)≠0.) # rounds, stone
≡(&p/+≡Count¤: ⊜⋕⊸≠@\s "125 17")[25 75]
And now we get into the days where caching really is king. My first attempt didn’t go so well, I tried to handle the full list result as one cache step, instead of individually caching the result of calculating each stone per step.
I think my original attempt is still calculating at home, but I finished up this much better version on the trip to work.
All hail public transport.
C#
List<long> stones = new List<long>();
public void Input(IEnumerable<string> lines)
{
stones = string.Concat(lines).Split(' ').Select(v => long.Parse(v)).ToList();
}
public void Part1()
{
var expanded = TryExpand(stones, 25);
Console.WriteLine($"Stones: {expanded}");
}
public void Part2()
{
var expanded = TryExpand(stones, 75);
Console.WriteLine($"Stones: {expanded}");
}
public long TryExpand(IEnumerable<long> stones, int steps)
{
if (steps == 0)
return stones.Count();
return stones.Select(s => TryExpand(s, steps)).Sum();
}
Dictionary<(long, int), long> cache = new Dictionary<(long, int), long>();
public long TryExpand(long stone, int steps)
{
var key = (stone, steps);
if (cache.ContainsKey(key))
return cache[key];
var result = TryExpand(Blink(stone), steps - 1);
cache[key] = result;
return result;
}
public IEnumerable<long> Blink(long stone)
{
if (stone == 0)
{
yield return 1;
yield break;
}
var str = stone.ToString();
if (str.Length % 2 == 0)
{
yield return long.Parse(str[..(str.Length / 2)]);
yield return long.Parse(str[(str.Length / 2)..]);
yield break;
}
yield return stone * 2024;
}
Rust
Part 2 is solved with recursion and a cache, which is indexed by stone numbers and remaining rounds and maps to the previously calculated expansion size. In my case, the cache only grew to 139320 entries, which is quite reasonable given the size of the result.
Solution
use std::collections::HashMap;
fn parse(input: String) -> Vec<u64> {
input
.split_whitespace()
.map(|w| w.parse().unwrap())
.collect()
}
fn part1(input: String) {
let mut stones = parse(input);
for _ in 0..25 {
let mut new_stones = Vec::with_capacity(stones.len());
for s in &stones {
match s {
0 => new_stones.push(1),
n => {
let digits = s.ilog10() + 1;
if digits % 2 == 0 {
let cutoff = 10u64.pow(digits / 2);
new_stones.push(n / cutoff);
new_stones.push(n % cutoff);
} else {
new_stones.push(n * 2024)
}
}
}
}
stones = new_stones;
}
println!("{}", stones.len());
}
fn expansion(s: u64, rounds: u32, cache: &mut HashMap<(u64, u32), u64>) -> u64 {
// Recursion anchor
if rounds == 0 {
return 1;
}
// Calculation is already cached
if let Some(res) = cache.get(&(s, rounds)) {
return *res;
}
// Recurse
let res = match s {
0 => expansion(1, rounds - 1, cache),
n => {
let digits = s.ilog10() + 1;
if digits % 2 == 0 {
let cutoff = 10u64.pow(digits / 2);
expansion(n / cutoff, rounds - 1, cache) +
expansion(n % cutoff, rounds - 1, cache)
} else {
expansion(n * 2024, rounds - 1, cache)
}
}
};
// Save in cache
cache.insert((s, rounds), res);
res
}
fn part2(input: String) {
let stones = parse(input);
let mut cache = HashMap::new();
let sum: u64 = stones.iter().map(|s| expansion(*s, 75, &mut cache)).sum();
println!("{sum}");
}
util::aoc_main!();
Also on github
Haskell
Yay, mutation! Went down the route of caching the expanded lists of stones at first. Oops.
import Data.IORef
import Data.Map.Strict (Map)
import Data.Map.Strict qualified as Map
blink :: Int -> [Int]
blink 0 = [1]
blink n
| s <- show n,
l <- length s,
even l =
let (a, b) = splitAt (l `div` 2) s in map read [a, b]
| otherwise = [n * 2024]
countExpanded :: IORef (Map (Int, Int) Int) -> Int -> [Int] -> IO Int
countExpanded _ 0 = return . length
countExpanded cacheRef steps = fmap sum . mapM go
where
go n =
let key = (n, steps)
computed = do
result <- countExpanded cacheRef (steps - 1) $ blink n
modifyIORef' cacheRef (Map.insert key result)
return result
in readIORef cacheRef >>= maybe computed return . (Map.!? key)
main = do
input <- map read . words <$> readFile "input11"
cache <- newIORef Map.empty
mapM_ (\steps -> countExpanded cache steps input >>= print) [25, 75]
Does the IORef go upwards the recursion tree? If you modify the IORef at some depth of 15, does the calling function also receive the update, is there also a Non-IO-Ref?
The IORef is like a mutable box you can stick things in, so readIORef returns whatever was last put in it (in this case using modifyIORef'). “last” makes sense here because operations are sequenced thanks to the IO monad, so yes: values get carried back up the tree to the caller. There’s also STRef for the ST monad, or I could have used the State monad which (kind of) encapsulates a single ref.
