Advent of Code - adventofcode.com

I kept track of the instances of each character in a map. Added the next char and removed the one n back. Uniqueness testing was simply asking the map how many entries it had in it, if it was n then job done.

Of course, I did manage to fail to pick up on the case where the first n chars in the string are unique, but that's unlikely to be the puzzle input, but it's fixed now.

I don't really worry about optimising the early puzzles too much, all so far run in under 0.002s so I'm still on track to keep within my 1s budget.

Bitsets ftw

#[inline]
fn unique(s: &[u8], n: usize) -> bool {
    s.iter()
        .fold(0u32, |acc, &c| acc | (1u32.wrapping_shl(c as u32)))
        .count_ones()
        == n as u32
}

fn solve(inp: &[u8], n: usize) -> usize {
    if let Some((i, _)) = inp.windows(n).enumerate().find(|(_, win)| unique(win, n)) {
        i + n
    } else {
        unreachable!()
    }
}

pub fn part1(inp: &[u8]) -> usize {
    solve(inp, 14)
}

pub fn part2(inp: &[u8]) -> usize {
    solve(inp, 14)
}

Just tidied up my day 4 solution. for-comprehension-tastic.

local input = std.rstripChars(importstr 'input', '\n');

local is_pair_overlapping(pairs) =
  local p1_l = pairs[0][0];
  local p1_r = pairs[0][1];
  local p2_l = pairs[1][0];
  local p2_r = pairs[1][1];
  (p1_l <= p2_r && p1_r >= p2_l)
  || (p2_l <= p1_r && p2_r >= p1_l)
;

std.length(std.filter(is_pair_overlapping, [
  [
    [
      std.parseInt(x)
      for x in std.split(range, '-')
    ]
    for range in std.split(line, ',')
  ]
  for line in std.split(input, '\n')
]))

day 6 didn't seem so bad

local seqlen = 14;
local uniq(arr) = std.length(arr) == std.length(std.set(arr));
local findfirst(arr, x) = std.find(x, arr)[0];
local finduniqseq(arr, len) = [
  uniq(arr[offset:offset + len])
  for offset in std.range(0, std.length(arr) - len)
];

findfirst(finduniqseq(importstr 'input', seqlen), true) + seqlen

Not very performant (it computes uniqueness over the whole input, then finds the first occurrence)

Definitely had a case of rushing into things with today's problem and ended up paying the price with debugging part 2, which took some hours in total if I'm honest.

Definitely a bit of a jump between yesterday and today's. Wasted a fair bit of time trying to recursively calculate the aggregated directory sizes after building the file system.

Once I calculated the dir sizes as I went along building the file system, it was much easier.

let fs = {}
let dirHistory = []
let currentDir = fs

arr.forEach(i => {
  if (i === '$ cd ..') {
    currentDir = dirHistory.pop()
  } else if (/\$ cd [a-z]+/.test(i)) {
    dirHistory.push(currentDir)
    let dirName = i.match(/[a-z]+/g)[1]
    currentDir = currentDir[dirName]
  } else if (/dir [a-z]+/.test(i)) {
    let dirName = i.match(/[a-z]+/g)[1]
    currentDir[dirName] = { size: 0 }
  } else if (/[0-9]+/.test(i)) {
    let size = Number(i.match(/[0-9]+ /)[0].trim())
    currentDir.size += size
    dirHistory.forEach(histItem => {
      histItem.size += size
    })
  }
})


let sizeArr = []
let getSizes = obj => {
  sizeArr.push(obj.size)
  if (Object.values(obj).length < 2) {
    return
  }
  return Object.values(obj).filter(i => !Number.isInteger(i)).forEach(getSizes)
}

getSizes(fs)
sizeArr.filter(i => i <= 100000).reduce((a, i) => a + i, 0)

How'd you enclose code in a collapsible box? I thought it wasn't possible

Thought I knew. Spoiler tag, but evidently I dont

Looks like markdown code tags aren't supported, but html pre tag is.

<details>
<summary>Spoiler</summary>
<pre>
Code here
</pre>
</details>

No spoiler tags or collapsible boxes on LFGSS. Every day is a school day.

Stick it in a gist and link to that is the easiest way.

Also reminds me to post a link to jwo's amazing graphs for completion times for the top 100. Useful to get a handle on where the difficulty comes.

https://github.com/jwoLondon/adventOfCode#completion-times

three backticks works for code blocks

Still a bit Meh so far. Just stuff that is a bit of a chore to chug through.

Looking forward to the first meaty one, sometimes due around now, at least within the next week...

Day 8 and programs take 0.021s so far, and I've put very little effort into optimising them.

I do like the ones that create an image which is the answer. (Day 10)

I liked today's challenge too. My first thought was that the part2 would fill my ram but nop just a fancy lcd.
I don't know if it's me but so far I find this year easier than previous one.

My day 8 part 2 takes 2m40s

I should try it in jsonnet as we use it all over the place as the basis for our Infrastructure-As-Code (along with Terraform, which someone has done AoC in too).

I could have sped mine up and simplified it by simply not considering the edges (edges get the -2 special case treatment as a crude workaround but it would be simpler to not even consider them)

I felt too ashamed and did this. It was an improvement. Shaved 4 seconds off too.

Ha.

Day 11 and the first (IMHO) proper twist for part 2. I've done too many AoC puzzles that I'd spotted it whilst I was still writing the code to parse the inputs. Divisor tests are dead giveaway.

Day 8 and programs take 0.021s so far, and I've put very little effort into optimising them.

Day 11 done and down to 0.019s total. Went back and optimised a few of the worst offenders. All taking 0.001s or 0.002s (as timed by sh's time). It's only Day 9 taking 0.003s and Day 11 taking 0.004s otherwise.

(This may all become moot if Eric throws a stinker in, but I've managed some of the previous years in under 1s total execution time before. Slowly sorting them all out and putting them in one repo but it's taking a while as I'm redoing them all in Go.)

Day 12: Djikstra-esque algorithm searching from the end point back. Both parts done in 0.002s.

day 10 takes under a second, which I think I'm happy enough with. Didn't even need to specify an extra large stack size.

Day 13:

Ugh. Parsing was ok, but I didn't have a previous version to copy from so had to do it from scratch in a new language, but got there reasonably ok.

But got myself in a tangle for the problem itself, not helped by my code working fine for the example cases but not giving the right answer for my input. Took too long to find the logic error(s) and get the right answer submitted.

At least part 2 was easy once this was sorted out.

Long time lurking AoC enthusiast...
I did like the IntCode from a couple of years back, but I guess the smaller non-interconnected puzzles are more accessible and more advent-calendar-ish.
Day 13 was fun. First thought - lets make trees and do a DFS to compare them!
Second thought - the strings are actually already in DFS order. So just use them directly.
Third thought - why don't I get the right result for the puzzle data when the examples work? Oh. 10. My regex stupidity. Every day is a school day.
Anyway. Kotlin for me this year. Repo here for anyone interested: https://github.com/gresty-dev/adventofcode2022

Think I have 13 part 1 done but Debian broke Firefox in latest unstable and I'm too lazy to get my yubikey from upstairs to log into github on another browser so I can submit my answer