andremedeiros/advent-of-code-2017

advent-of-code-2017's Issues

Optimize the scanner walker

Instead of subtracting full loops, and figuring where the scanner is and what direction it's on, I've got a sort of brute force situation going on where I simulate the walking step by step.

Optimize this away to cut some cycles.

Checksum the memory banks

Every time a bank gets reconfigured, I take a snapshot and record it, which makes it incredibly inefficient. I should potentially find out whether there are methods to checksum a list of integers.

Find ways to optimize the anagram detection

One of the things that's bothering me with my solution for the 2nd part of the problem is that I'm effectively converting each string to a slice of bytes, sorting, and converting it back to a string. This was my first idea of how to detect an anagram. Need to find out whether there are better ones.

Also, strings in Go are immutable, so any sorting that would happen would always involve some allocation work (and the character swapping would be a mess of substring calls.) The byte slice is probably the most optimal solution here as we allocate an extra string and a slice instead of potentially n-1 strings, n being len(str)

Make the parser Ragel file output into `main.go`

I've got the Ragel output coming out in parser.go which means the running command for day 7 is slightly different than the other days'.

Migrate the parser into main.go and generate that instead.

Improve tests

Because I refactored day 12 to use a graphs library (and oh boy, what an improvement that was!) I need to test the counts and groups, etc etc.

Add tests to ensure that those values are correct when returned. This could be a great opportunity to wrap/extend interfaces.

Implement matrix iterating logic

Need to figure out how to get the matrix iteration going. From what I've figured out, the logic is this:

• Start at (0,0) with value 1
• Move 1 right
  • Increment value (now 2)
• Move 1 top
  • Increment value (now 3)
• Move 2 left
  • Increment value (now 4)
  • Increment value (now 5)
• Move 3 down
  • Increment value (now 6)
  • Increment value (now 7)
  • Increment value (now 8)

The logic is self evident, but I don't want to brute force. Instead I'd like to derive a shortcut to get to how many moves we can fit inside a number before we calculate how many increments it takes to get to it.

This type of matrix is visually represented like so:

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

Implement cleaner integer division logic

The logic for integer division checking is kinda fucked up. There are extra checks that make me feel this solution is quite sloppy.

One solution I thought about was to do a reverse sort of that slice and iterating through that instead, so we're given that guarantee at least.

Most likely there's an even better solution that I just can't think of right now.

Avoid doing potentially unnecessary up front conversion

When reading the input, I do an up front conversion here.

This really doesn't add that much value, as comparing bytes and integers should be comparable, but adds an extra allocation and makes the program slower than it should be. Instead, I should avoid doing this work and only convert when I find a pair of matching numbers.

Refactor to accept a modifier function

There's a fair bit of repeated code here, which makes me itch for a cleaner solution.

The only bit that changes is the part where we decide how the offset gets affected, so maybe accept a function that accepts the offset value and returns 1 or -1, depending on how the offset needs to be affected.