Advent of Code - adventofcode.com

Nothing interesting to see in mine. Boring array wrangling

https://github.com/jyates13/aoc2021/blob/main/d5/d5.py

You can make the iteration much neater with zip_longest: https://gist.github.com/wence-/500e1bc4633192ac6fee67433aedd974#file-day05-py

bit behind as I had family staying at the weekend. ended up skipping day 3 pt 2 as it all felt like a bit of a clusterfuck. just finished + quite happy with day4 tho, first time I actually needed to implement some parsing rather than just using editor commands the make the data the right shape. https://github.com/ZooeyMiller/advent-of-code-2021/blob/master/Day4.hs

A fun one today, saw part 2 coming from a mile away

https://github.com/willjrh/Advent-of-code-21/blob/main/day6.py

I also enjoyed today's

https://github.com/jyates13/aoc2021/blob/main/d6/d6.py

Nice, never really dug into itertools too much...

Alright, finished day 1. I may be doing this for the whole of next year too at that rate.

On the plus side, I'm starting to get my head around ScalaTest.

I do enjoy the cases where I just have to change a parameter value to get part 2.
frequencies and iterate in the standard lib made it a bit easier to model.

https://gist.github.com/dmckennell/d9a52000647c7ed59cd63873579c6f91

I really liked this one. Using a circular buffer for the fish counts you can reduce the simulator loop to a single addition.
https://github.com/cgresty/adventofcode2021/blob/main/src/main/java/dev/gresty/aoc2021/Day06.java

What are people's strategy for project structure and version control? I'd ideally like to work on all of the challenges inside the same project but without separate classes for each day's solutions.

I don't mind throwing away part 1's implementation of something (and tests) if I can get back to it via switching branches or something.

Many people seem to use github and do separate checkins for part 1 and part 2 - at least in the early stages where you're not ending up doing massive reworks just to get one part done.

For project structure I just have:-

~/personal/aoc/<year>/<day>/

• <day>.ex - example input
  
• <day>.inp - my real input
  
• <day>.{go,pl,c} - program
  
  

I also tend to have a template.pl (or .go) file in the <year> directory that I use that just contains the basic structure.

I am planning to go back and redo all years in Go in order to learn it, when I do that I'll try and remember to do checkins as I go (at least between p1 and p2).

Enjoyed today's because my brain was frazzled: https://github.com/rhowe/aoc/blob/main/06/6part2.jsonnet

~370ms in jsonnet for part 2, can live with that.

Catching up - just finished day 3. Was there a neat way of doing the life support stuff without a loop? Recursion?

https://github.com/owlz84/advent21/blob/d03p2/src/main/scala/org/stuart/advent21/Diagnostics.scala

Also, have unsigned integers never been a thing in Java-land? Was disappointed I couldn't just flip the bits once gamma was an integer.

im(gonna(eat, you(little), fishy))

Nice solution, compact.

Was there a neat way of doing the life support stuff without a loop? Recursion?

That's what I did. Do excuse the dubious "optimisations" with bit operators:

def prune(inp: list[list[int]], bit: int, flip: bool) -> int:
    keep = flip ^ (sum(b[bit] for b in inp) >= (len(inp) + 1) // 2)
    filtered = [b for b in inp if b[bit] == keep]
    try:
        (x,) = filtered
        n = len(x) - 1
        return sum(c << (n - i) for i, c in enumerate(x))
    except ValueError:
        return prune(filtered, bit + 1, flip)


def part2(inp: list[list[int]]) -> int:
    # inp is a list of binary numbers, each represented as a list of bits.
    return prune(inp, 0, False) * prune(inp, 0, True)

So far I always make sure that when i finish, I have one program that runs once and returns both answers neatly. Since 2 is basically always an extension to 1, you should be able to build on it, instead of redefining and redoing stuff. I think it's good practice to write a complete, self contained, program for each day.

This means I just have one repo with one branch and a folder for each day, containing one input file and one script. Well, so far at least

Enjoyed today again. Here's my overly general suboptimal solution

https://github.com/jyates13/aoc2021/blob/main/d7/d7.py

Day 4 done, I have some serious catching up to do.
https://github.com/owlz84/advent21/blob/d04p2/src/main/scala/org/stuart/advent21/Bingo.scala

Discovered takeWhile. I thought that was just a python thing.

skipped day 5 in favour of the fishy thing

https://github.com/owlz84/advent21/blob/d06p2/src/main/scala/org/stuart/advent21/Lanternfish.scala

Day 7. Yeah, I copypasta'd someone else's recursive function summing an arithmetic progression. Don't judge me.

https://github.com/owlz84/advent21/blob/d07p2/src/main/scala/org/stuart/advent21/Crabs.scala

That arithmetic sum is pretty funky... But you could have just done n(n+1)/2 😅

If you're aiming for optimal then it's almost certainly less computationally intensive to precalculate all of the values using addition rather than using Gauss' formula each and every time you need a value.

Is that what it's doing? I don't know anything about scala.

I tried to memoize my Gauss results - it was slower than recalculating every time. The list is pretty short I suppose.

You don't actually need to run any optimisation for fuel anyway. Median and mean should be within 1 of the right answer for part 1/2 respectively. You just have to check the nearest couple of ints

There's no right or wrong. I'm talking about optimising by minimising calculations. Using the median and mean values (or floor/ceil of those) is going to be a huge optimisation on the naive algorithm of calculating every possible answer.

No idea about Scala (haven't even looked at that solution) as I've no idea about how its memoization works.

But, at some point, pre-calculating the values using simple addition *may* be faster than repeated multiply/add/shift. It all depends on how sparse the data is. I'd have to start to play with a dataset that is orders of magnitude greater in size to have an idea, and it's just not worth it really. The "trick" with this day was using the values near the mean/median.