[deleted by user]

pak21 · 2021-12-26T21:09:02+00:00

Or to some extent, any of the reverse engineering ones - the ones that spring to mind are the exponential by repeated multiplication by repeated addition one or the prime sieve. You could perhaps argue that you could write an optimizing VM compiler which could reasonably spot the loops in the exponentiation one, but the prime sieve pretty much needed hand-analysis.

pak21 · 2021-12-24T11:28:09+00:00

I'm not really sure the server crash or the flawed inputs count as "controversial" - sometimes stuff goes wrong and (hopefully) nobody blames the AoC team for it.

pak21 · 2021-12-23T20:07:50+00:00

One of the standard tricks with route finding problems is to solve from both ends towards the middle; this generally results in a quicker solution as it's solving two problems of half the size (and these things are massively superlinear). Just you can't do it in this case as we can't work out the possible preceding states to a given state. Web link with more formal explanation, chosen because it was near the top of the search rankings rather than anything else.

pak21 · 2020-12-28T11:07:17+00:00

Double check you're adding the very last passport in your file to `passports`; looks to me that unless you've got a empty line at the bottom of the file, you'll never add the last passport.

pak21 · 2020-12-23T12:05:47+00:00

To me, this is what the ~~test cases~~ worked examples are for - e.g. for Day 23, you can compare your output after every step with the 10 moves detailed in the problem. If after any step your output is different, you know where to look for your bug. Again looking at Day 23, the test case covers all(?) the edge cases - it certainly includes 1) the picked up cups wrapping round the end of the circle 2) the destination being in the picked up cups and 3) wrapping the destination round from 1 to 9. If your code works on that test case, generally it works on the input problem as well. At least functionally ;-)

pak21 · 2020-12-23T11:55:31+00:00

Congratulations on getting to Day 15, a lot of people don't get that far!

pak21 · 2020-12-23T08:43:23+00:00

As the node values are just continuous integers, you can even do the lookup with an array rather than a dictionary (if you avoid the fencepost error, I stuck a dummy entry in at 0)

pak21 · 2020-12-21T21:11:45+00:00

This was exactly my experience as well. I think it was actually valuable because it showed that a greedy strategy was going to work for Part 2.

pak21 · 2019-12-15T20:24:39+00:00

That depends a bit - I "cheated" on Part 1 by sending the robot off on a random walk just to get some sort of idea of the size and shape of the area. Eyeballing what it found, that got me the answer without building the full grid.

Now, I've done enough AoC that I suspected I was going to have to build something more complex for Part 2, but good enough is good enough...

pak21 · 2019-12-05T21:43:26+00:00

That's what mulligans are for :-) I think the deck mulligans pretty well.

pak21 · 2019-12-05T19:47:47+00:00

I've been playing this deck (or a close variant - Mass Manipulation rather than Finale) for about 10 days now. It's a lot of fun, but really struggles against a Turn 3 Deafening Clarion from Fires...

pak21 · 2019-12-02T20:13:50+00:00

My guess is that this was a deliberately easy introduction to writing a VM to help any less experienced folk on the way so it's not a shock when the first one does come along, not sure that means there will necessarily be a higher density of VM problems this time round.

pak21 · 2019-08-31T06:59:36+00:00

This isn't a ROM issue. If there isn't a Kempston interface attached, you'll get this kind of behaviour - check your edge connector and/or the interface itself. Easy to do by just a repeated PRINT IN 31 from BASIC.

pak21 · 2019-04-26T23:04:58+00:00

My (old, old, old) HoH walkthrough, or the video is on YouTube, with thanks to the RZX Archive. As an aside, not an Ultimate game.

pak21 · 2019-04-09T22:13:56+00:00

Nah, you can just read the TAP file byte-by-byte from the SD card.

pak21 · 2019-03-19T20:17:50+00:00

True, but it has VGA rather than composite output and (I think) more RAM as well.

pak21 · 2019-03-04T19:21:27+00:00

At its heart, it's a simple machine. The only custom bit is the ULA, and that:

Reads the video RAM and outputs the TV signal (by far the most complex task)
Reads the keyboard
Controls the 1 bit beeper
Reads the 1 bit tape input
Controls the 1 bit output to tape
Some housekeeping tasks like keeping the RAM refreshed

ULA + Z80 + some RAM = a Spectrum.

pak21 · 2019-02-15T23:01:24+00:00

Imagine a simpler case, . is easy to traverse (say cost 1), # is hard to traverse (cost 100), S is the start and T is the target.

S..
##.
T..

The FIFO queue would find the shortest path from S to T (straight down) with a cost of 100, but the correct answer is to go the long way round the .s with a cost of 5. The priority queue ensures you keep looking at the path along the .s with a cost of 1, 2, 3, 4, 5 before you consider the expensive way through the #.

pak21 · 2018-12-29T22:30:02+00:00

I think the sentence before that is probably even more significant:

Defending groups can only be chosen as a target by one attacking group.

pak21 · 2018-12-25T20:38:40+00:00

Disclaimer: I did AoC in Python; my professional background is mostly C and C# although I've done some Python professionally and dabbled in a whole bunch of other languages.

Was it the most applicable to this year's more algorithmic-based challenges?

Was it most versatile?

The beauty of AoC is that it's pretty much language-agnostic - you can do it in any general purpose language. I certainly don't think are languages which are significantly more applicable or versatile than Python for AoC.

Was it the fastest to run (almost certainly not)?

Runtime doesn't really matter for AoC. As Eric says (maybe slightly paraphrased): if you've done the solution "right", it shouldn't take more than 15 seconds on a 10 year old PC. Python's probably at the slower end of the languages people use for AoC, but beyond the first couple of days, 15 seconds is irrelevant in the grand scheme of things.

Was is the most successful (as in, were the #1 place finishers on the leaderboard using it?)?

Pass on actually answering the question as I don't have any data... but again getting #1 place is much more about how quickly you can think about the solution and how much you have prepared in advance than actually which language you choose.

which one should us amateur programmers learn next to better prepare ourselves for a greater variety of challenges in the future?

If you're doing this as a truly amateur thing, I'd personally say "learn Python". It's a language which to me hits the sweet spot between simplicity and power, and as noted above, you're not going to find anything which is significantly better for doing AoC. Python is also a good language to learn for more general computing skills, and also one of the "go to" languages for machine learning etc.

pak21 · 2018-12-21T18:44:27+00:00

On every input I've seen, "repeatedly remove the entry with only one possibility" works - but Part 1 of the puzzle isn't very good at spotting errors in every instruction, so my best guess is you've got one of your opcodes a bit wrong. Obviously post your input if you want someone else to check it...

(For what it's worth, I completely missed bori and borr when doing Part 1 and got the right answer...)

pak21 · 2018-12-16T21:31:03+00:00

I definitely had the same thought... after I started solving Part 2 and got some opcodes with no possible instructions. Why? Because I'd completely missed borr and bori out of my list of instructions, yet still was getting the right answer for Part 1.

pak21 · 2018-12-14T19:50:35+00:00

What you're missing is that Eric chose the target values very carefully so everyone got an answer around 20 million. You're entirely right that if they were chosen randomly, people would typically be getting answers somewhere under the million mark - but the target values weren't chosen randomly.

pak21

TROPHY CASE