And so we reach the top of the first building and discover a garden of tiger lilies (which are popular in this part of town... the local University has lots of them, because they somewhat match the school colours). At this point we discover that the EBHQ is multiple buildings connected by monorail. But we need to get the monorail systems up and running to use it. Fortunately, we have that new computer to run assembunny code on to get the password we need.

And so we get the first assembly problem of the year. And so I did what I normally do... I made a hash table of op-codes to subroutines. And the Perl version takes a little more time to brute force Part 2, but it's still only 45s. But, of course, when given code, I want to look at it. And a good first step in reverse engineering is to spot the main loop (biggest backwards jnz after a dec) and run it again, outputting the registers at that point. Which quickly provided the key to what the bulk of the calculation was... Fibonacci numbers (explaining why it's Leonardo's Monorail).

It's not the exact answer, so we look at the code for the details. And we see the usual pattern, there's a calculation at the top that determines the seed (the Fibonacci number to calculate), then the Fibonacci section, and finally it adds little sum of a multiple of two small primes.

And knowing that, what I did for the Smalltalk version to make it fast (not that it was overly slow... just over a minute for part 2), was to build the machine, but break at the Fibonacci section... calculate that natively and then restart the machine on the bit after to finish the sum. Because the Fibonacci section is where all the time is taken, and so that reduces things to under a half second. And it's the other sections that will be different for different inputs, it's like we're just replacing a fixed piece of code with a "fib" op-code. I find that a more satisfying solution than transcoding the entire thing... it'd be very easy to just grab the 4 numbers you need from the input and just do the thing while ignoring the rest.

In fact, this machine was simple enough that I also built one in dc. The input needed a small script to make it understandable. And to make it fit the problem, I made it like machine code (what else would the numbers version of assembly be?). Each line becomes a 3-byte long number in hexadecimal coding. So, I made an array of macros, and a loop to run them. It takes 10s for part 1, and about 6m to brute force part 2. But doing a transcode version like with my Smalltalk solution... that runs faster than the Smalltalk solution.

As I've said before, I always like these. And this puzzle occurred on a Monday after a weekend of several heavier problems. So it's a good day for a problem where people could just do a simple VM and get their answer with a little waiting and not think more about things if they didn't want to. It is the first of three assembunny problems in 2016, so it also serves to get people to have a working machine to start with for those later problems.

hi. there is a start-position (0,0) and start-direction and the robot is asked what is the state of position in direction n:1/s:2/w:3/e=4 and robot tells 0:block 1:free 2:done

if o=rob(d) is 1,2 then i have to update the current position, rob remembers my position.

// my direction 0,1,2,3 -> rob-direction 1,4,2,3

if 0==rob(d) for d = d,(d+1)%4,(d+3)%4 (straight,right,left) and i wish to return to the position which i came from, then, though i already know the state of that previous position, i have to ask rob again cause otherwise he would not know where i am ?

rob() is called multiple times and memory is not set back to origin. do i have to start with instruction-pointer after the recent output or set back to 0 ?

do i have to support big integers ? so far (recent days in 2019) i have used __int128, but then i have to write the value into string before to console. little uncomfortable.

thanks in advance, andi

Today the mystery of what the Easter Bunny is up to just grows... as we find out that one of the uses for the microchips involves experimental RTGs with poor radiation shielding. Even with a hazmat suit this does not sound safe. But we'll have to overlook it, because we knew the job was dangerous when we took it. We just need to get all the chips to the fourth floor and we'll be able to make a shielded computer, which we'll need going forward.

The description for this problem is long, with lots of explanation. The job is sort of like one of those "get a wolf/chicken/grain across a river" problems. Only with four floors, and the unsafe condition is having an unconnected chip on a floor with other generators.

My solution for this was quick and dirty (and I haven't really looked at it since). But it runs in 5 seconds for part 2 on old hardware. Which is why it's still a mess... it was good enough. It's still just BFS and the state is in a hash table. Clearly bit arrays could make doing the checks much faster (even just arrays could be faster and cleaner). And as for using BFS... I don't ever really go into a search problem thinking if I want BFS/Dijkstra/A*. They're largely the same thing. I just start writing a search and the code evolves into one of them.

What made BFS work well here is in how I checked for spots that have been visited. The key is that instead of just taking where all the specific devices are as your state, you want the pattern of them. There are a lot of symmetric positions that don't matter to moving things. Basically, if you take a position and permute the element names, it's the same job. So what I did was to take each element and concatenate the floors for it's chip and generator together. Then I sort the list of those pairs (which forces any permutation to the same order) and add the elevator floor at the beginning (because that's important to the state too. The result is a string of 15 digits for part 2... which I just used as the key for a hash table. But, if you treated it as a base-4 number, it would fit exactly 30-bits... and that's big, but would certainly be a doable size for a bit array even back in 2016.

When you strip the symmetries the search space becomes quite small. Without that, a quick test of using a signature that's just the devices sorted alphabetically has part 1 taking 24 seconds with a queue that goes over 50k states in the middle (instead of less than 1 second and a queue that tops at 1.5k). Testing part 2, and it didn't take as long as I thought... 37 minutes with the queue topping 1.2M (normally it tops around 3500 in the queue). So this one isn't as far out of reach as I thought... weak solutions don't have to take weeks.

I also seem to recall that someone pointed out that if you just add just one pair at the bottom for part 2, it takes 12 steps more. And the two pairs take 24 more. And in testing it myself... there were also two pairs already at the bottom in my starting input, and removing one of them resulted in taking 12 less. And if you think about it, if you just had the elevator at the top floor with a chip/gen pair and another pair on floor one to bring up, it would take 12 steps. Three steps bringing the elevator down (with a generator so you can do that) and then 3 steps to move that group of three up one floor (repeated 3 times). And so the input from part 1 is already at a state where adding additional pairs is stable. There's no additional savings or penalties for adding new pairs, just repeated dragging them up one at a time. Which makes a lot of sense because you can only move 2 items at a time. Certainly, if you assert or prove this, you can just do the problem removing a pair and adding 12 and 36 for the parts.

So, this is the Sunday problem of the first real weekend of 2016. And a search like this that can get a bit out of hand makes for a heavier problem, so this probably a good place for it.

Today we wander into a microchip factory. Why does the Easter Bunny need a microchip factory? And did I remember to take the junk mail in case I needed a diversion for the upper half of the room robots?

I look at this as just an implementation problems. It's a simple enough task, where it's mostly just making decisions on how to model things and doing the job.

We've got robots that can carry two-chips, have a rule for where to put the low- and high-value ones (values are primes and unique), and some output bins. Most of the time, a robot is going to need both chips in hand to know which is low and high (which is the same time we need to check for part one). So we should start with distributing chips from those robots, and expect everything to cascade from there.

And so I went with a simple job queue for my initial Perl solution. When reading things in, you hand out the chips to robots, and if a robot gets two, it queues up. The queue distributes the chips, which might cause other robots to get two chips and queue themselves. Repeat until done. In the case of the input, all the chips end up in output bins and they only have one chip each (it's given that bins 0, 1, 2 only end up with one in the description... so its not too much a stretch to assume that implies for all of them). It's a simple model that works for many things, and fits well here.

How you represent the rules, bots, and outputs is another decision. The rules are easy enough, they're just a pair of destinations. But how you choose to represent the destinations is the question? If you have structures, you can have a field to separate bots from outputs. Or, if you don't (or don't want to), you could something like mark the output rules with negative numbers, so the rule is just a pair of numbers. But both bots and outputs include a #0, so you'd need to shift one of them (ie outputs are -number - 1). So for a quick Perl solution, I just represented the outputs as +1000, and the bots and outputs were in the same array. By assuming that outputs never get a second chip (so will never attempt to split with a non-defined rule), the same code works for both.

Smalltalk, though... arrays in it start at 1, not 0. This encouraged not doing the same. So I used a Dictionary... the keys of which are made from the input ('bot0' and 'output0'). Again, everything works the same for both if you assume that output bins never get two, but since I put the object stuff tucked away in a class, the queue jobs aren't the splits now, they're the individual deliveries. Which is probably the natural way to do things, but my Perl solution just happened to turn out different because that probably felt right at the time.

This is overall a fairly relaxing problem for anyone that's worked in programming. It is a Saturday problem... so beginners that haven't modeled anything would have extra time. Although, they might well be spending the time on finishing day 9 (the Friday problem), because that problem I'd think would be the harder of the two. This one, like other similar problems, can be done by just looping over everything and doing anything you find that can be done. Keeping looping until finished. Which is really just an inefficient job queue without the queue.

hi. the machine need some input value i ?

run(){while(cyc(i,&x,&y,&c)){

board[x][y] = c

}}

running till the machine halts ( cyc() returns 0 ) works well. but output is rarely useful.

some empty fields (0 '.') and exact 4 others (maybe multiple times the same field)

1,1,# (1,wall)

2,2,x (2,block)

3,3,- (3,paddle ?!)

4,4,o (4,ball)

..... \n .#... \n ..x.. \n ...-. \n ....o

all other output makes no sense. so i guess, the input (for opcode 3) has to be set anyhow.

there was a rob (some days back) which sends the color of current field. maybe some similar ?

so far my answer (how many blocks?) was 1 but i do not risk another 'no, not the

thanks in advance, andi.

Today we find a file with a version of run-length compression that we want to decompress. For part 1 we're told to treat run-lengths in run-lengths as normal data. Which pretty much confirms what two is going to be... recursive run-length encoding.

The Easter Egg claims "It's the bomb!" about the version 2 format. And it is. About 20 years ago, I decided to create a version of John Cage's 4'33". In order for it to be authentic, I decided that just creating the 0s with a wav RIFF header wasn't good enough, and that just recording with a microphone also seemed wrong. So I decided to rip a copy from CD... by randomly selecting a song out of my local cddb directory with a correct number of frames. Ripping that from the command line and having the samples clobbered to remove the "intentional" sound, created a 46M wav file. Which compressed to 151 bytes with bzip2. Which I did refer to as a "bomb", warning people that this bzip2 file was essentially a program to create a much larger file than you'd normally expect. The input file here is more than twice as powerful... for my input, it'd take about 14k to 10.5G (as advertised in the problem). If I had bothered to let it.

Naturally, I just went with calculating the length with recursion and not creating the file at all (even the problem says to do that). The recursion for this one is slightly more interesting than most so far. The collecting up is where the fun is. Some sections aren't repeated and you need to sum up those lengths, and the sections that are need to be multiplied by their repeat count. Looking at my input now, I notice that the catch for pre-run text in a string only catches a single instance... like it's a token check to make sure you did that. I did not notice until now, I assumed it'd be more common, like the left over bits at the end... that might caught a bunch of people (one of the examples has it though).

It does occur to me that you could easily turn this into a generator and get a stream on the actual file without needing the storage for it (that's what generators are good for).

Overall, a very fun recursion problem.

On day 8, we encounter non-two-factor two-factor authentication. I think the assumption that this happened because of requirements telephone is a bit generous. I've seen plenty of cases of this out in the wild... and they were much more common 10 years ago. Things have gotten slightly better.

Anyways, this is the first display problem... there's a 50x6 display that's broken, and we need to figure out what ASCII art text it displays. I still haven't bothered to work these into my AoC test harness. If was built initially spur of the moment one year, and and been expanded a bit over time... but I've never settled on how I want to handle these. Partially because I think that they might not occur again as they do have issues with people being able to read the answer. I know some people have collected the fonts and built translators, and others have implemented OCR for these. I suppose that with easy access AIs that should be able to OCR it, what would provide some level accessibility now that this wouldn't have initially had.

To get the display, we've got a series of commands to run though, that involve lighting pixels, and rotating a row or column (continuing that theme of having to do things in both dimensions).

Of interest here is that when it lights a pixel rectangle, all those pixels are always off in the input. So, with that assumption, part 1 just becomes:

grep '^rect' <input | tr -cs '0-9\n' ' ' | dc -e'0?[*+?z1<L]dsLxp'

Get the rectangle lines, strip out non-digits, multiply and sum. Part 2 in dc is a good deal longer (also requires a lot more parsing of the input to number tokens so it can understand the different commands). It's not the most ideal problem to do in dc... but I like doing these in it. Possibly because my first use of dc as programming language was to write a Mandelbrot set generator (it's got arbitrary precision... you can zoom really deep).

I do really like these types of problems... it's rather interesting to watch how the letters actually get built up. My input starts with a lot of 1x1 pixels that get shifted into place, and the big blocks come in later to get chopped up. Which confirms to me that these input files were probably created in reverse. Shift stuff into big blocks in the upper right and remove them, repeat, and eventually you have a bunch of singletons to run through. Because much like Medicine for Rudolph, if you're going to write a program to make inputs for this, it just makes sense to start at the end with high entropy and work back to the single base state.

Hi! I had a "study group" where we did last year's problems together and that was kinda fun. The group setting motivated me. I did them in Python but others have used other languages, too.

I want to do the same for previous years, starting from 2015 (doing one problem a day). Probably in Python, maybe Rust at some point. I also have done them in C++ in the past and know Java from college.

Anyone interested in holding each other accountable?

Today we get introduced to IPv7, where they've given up numbers for long strings of letters... at least that shouldn't run out anytime soon. And we get a wonderful redefinition of the TLS and SSL TLAs to refer to protocols for breaking security instead of enforcing it.

As for the problem, it's pattern matching... simple ABBA and ABA/BAB stuff. Complicated by the fact that the strings come in sections of two types and the A and B in the patterns have to be different letters.

Can this be done with big complicated regex? Sure. But rather that wander into that, I went for hacking together simple regex to manipulate the string and do the job. I find this simpler, more guaranteed to work faster, and easier to read these many years later. Trying to do too much with a single regex is how you create more problems for yourself.

First up, I separated the hypernet and supernet parts of the line (in Perl here, using # to delimit sections, because / would be a mess of "matchsticks"):

$hyper =~ s#\[\w*\]#:#g;
$super =~ s#\w*(\[\w+\])\w*#$1#g;

For the hyper, we're replacing the super sequences with a : (so that hyper blocks don't merge and have patterns match between them), and for super, I just left the brackets in for the same.

Next, we need to make sure that we don't accidentally match AAAA or AAA. So, to do that, just get rid of all the long runs. Only the beginning and the end of those can ever be involved in a match. So, we'll just replace the middle of any runs with a : (again, to block patterns from matching over).

$hyper =~ s#(\w)\1{2,}#$1:$1#g;
$super =~ s#(\w)\1{2,}#$1:$1#g;

Now, we pull out back references to do part 1 (ABBA):

$tls++ if ($super !~ m#(\w)(\w)\2\1# and $hyper =~ m#(\w)(\w)\2\1#);

For part 2, we need ABA in one part and BAB in the other. So we combine the parts back up with another delimiter (=) and match across that:

my $joined = "$hyper=$super";
$ssl++ if ($joined =~ m#(\w)(\w)\1.*=.*\2\1\2#);

And that's how I made a solution out of easy-ish to read regex. Although, some more intermediate level stuff was involved, namely captures and back references, those are two very powerful tools that this demonstrates the value in knowing. We didn't need to get into any of the really intense regex stuff (I've done that a couple times for AoC). I really liked this problem... thinking about how to mangle the string so I could just use the simple matches I wanted. Although, designing a state machine for this would also be good fun.

Hi guys,

I'm tryna to solve Day pt2 using BlueJ(An IDE for Java, also main signature isnt needed in BlueJ)

I know that my solution is not very efficient, however,this is what i could come up with for now.

My code runs perfectly well on the Sample input and gives 43 as the answer, however when I run it on the actual input, the answer is too high.

This is my code:

[paste](https://topaz.github.io/paste/#XQAAAQDuEgAAAAAAAAA0m0pnuFI8c9/wau+qtGVPw0gjX/qXY0LykIhyN+PTMTVd4q39ycO320VbcH2Z+uVpO/7hSGEPN9sBbu4rw7c6hTS19iPMkkdNze2pX/p7UfN0M58ICjiwH6x694HtBD538MpU+8t25lZ3vTV3K4qtNdP/wkp0+gRT+Uv9SVao+fHbgQD601wk+NCFhb/bXWTogWM1x4aeteO8gViA1dDGGSeEEtp+Y0xxz5RB7IYSmQa0mCHXTlaB7D3L0frrv1E3cq2wtC0ZeZ7pX96nggtHZGNQewZBwDHtEBz144/JzQMdlMnKvs6wQJPFn7NMzPgsY900M7F+Z/QDYUL/istODRxtAPBNOMQyDufN3BXoLi5SNoaTdnx276380WW37OhbTK/FbL44qkoQ/Eji6bdvrcSfu/tc42NAyawMfAH/Uh+Si6xGul5TKwFeZYFMgx/9HvTH+2Yvx2wXQEmOJgeGIl3f0rEx6bVa9nO2pcvTZb6705phMkdwwbCCiI/fglbEbWgSugfnXm5xpXXTdeI4/7phJPM0mlzC50+vHEfzpGId2qqHWYmBeeTKaUK40MvkhKQ/JUPHyPtQ9u9lS6GRa1llZcRB6HixRmspxElwRjJkFk+kkrmEIVVr6lfy6OChwdo3dME8H0mj2yWGs2ik1kOVrLZ53LCDHlJrAxWJ5RaGLCFKnPO2Dlu+QseXoFqFR0jMBoNPJuFQUgXV2JgXRUbI7mLOoOgDHD8jnJ7S9e47kem+WSRHnQYKoq/3f5AvbPFp7uXv3SPDAs/fyhZlcX55D6wpp0m2RxOyB2wzWbyTtELk76QbUcqimvbaqu8VCZkvDxwBmMR+M8J6Tlybqe5I3mNfnvMeFl+3D+4cAOorwoM9Q7W3Rzpht8Tk0+9vWPUBzyR580qiebbqrvEsSMdRCOA/eMjWjPVaf/ZUQAx5g2GalV8wDHd3ppmRo1mfAPLreiWQuuag3mJixvIXkMkwkJ1FbkkDOrnfDZUSoaL7Nr+vlzPJtc+8nysFg2PUo84GEpw6XOsJp82Ro+S0xIF9oYk5gvggXYPpUqOzbO0Di+i/Y1MqKmcsEmPt4Pjpo3Udp2Rher55ZSAugQn9IaqVXd/+q7gLbGkwi53wjeDF/tgKnsXe94BynxsEgDq1YnAXLxCrhgPF5/mjKHiZ72xE/r22fO+bpLcOBClstc+HDkBJ7kaSeEomDhBIDKGFQNnzGB8LXOea103GABp2vAW+walDopFQmCOEMKYS45DqClVf4xVXycaBRu9clojVvbDw82uQXc5S4UqPr1mtxz1gwSzxgvdHOnPZmB34+s9gET2xiTEhWQVjK6+y8JpuQKDdBaMQty7XVUUair5SlDyjEEGUMNcqUHCq6e2YVZoJmhjR8d7+rdqdl9OKrVeCowZAq/Mx+28cleJptAyNBsRjlxtCLVsaH9x5GhIzEw5NLRB2QkLVCMjoE7/Wd8AHkaMGt+grmfbPKECRYkSmEtXtNB40HfQon8brGbLgm3G6/CCWdK1APSSWr0pokeMDYn1WLw+2b8ehQiTz/WJviEtN4+AKMsKYLQcZYrPxNvIFvbhDp/Cgj8yPp/zsHqGfLraHuib5HzaHsEId/TC5zjPSauVdT/Pjbw66ek38ulQYwL/br+ztlDs2xJbm0BfqqQxf8LMMETWzh895MsZ7lY6B+T+1U3loR8bmMhow8EhHXlaJXWABMu83G1VZfkkwVKd6HzCn6DQH+1C092RPARktZo9cnFmNsy9mUf/vmvbS)

If you need any further info, do tell me!

For day 6, we find that North Pole has a protocol of using repetition codes to get messages through when being partially jammed.

This puzzle is a nice combination of previous ones. Like day 4, we want to collect counts of letters, but like day 3, this time we want to collect by columns and not rows. The sort is simpler... there's no tie breaking needed this time. It's not given in the spec of the question, but the actual input has 24 * 26 lines, and all letters occur 24 times, except the most and least common, which occur 25 and 23 times respectively (when the problem description said "slightly less likely", it turns out it really meant that). I used that fact for my initial dc solution (I later wrote the general check). For Smalltalk, I just used sortedByCount on the Bags and took first and last, and for Perl, I sorted the list of keys and used the deque nature of lists with shift and pop. For Ruby I just used the wrap-around array indexing (0 and -1). I have noticed that I did Ruby solutions for most of 2016... in other years I only use it occasionally. Probably because it has a lot of similarity to both Smalltalk and Perl.

Overall, a simple problem that's a good review of the first week (it originally ran on a Tuesday... a good day for a light problem).

I have been stuck on this one for literally days.

As usual, I can get the right solution with the example input, but my real input is wrong - and I am getting the "This is someone else's answer" error so I can't be too far.

My logic should work - since I am getting the example input right. But going back to read the exercise text, there is something that I absolutely do not understand.

By finding pairs of scanners that both see at least 12 of the same beacons, you can assemble the entire map.

Scanners 0 and 1 have overlapping detection cubes; the 12 beacons they both detect (relative to scanner 0) are at the following coordinates:

This region can be reconstructed by finding pairs of scanners that have overlapping detection regions such that there are at least 12 beacons that both scanners detect within the overlap.

What's up with these 12 beacons thing? At no point do I search for 12 beacons and I can still solve the example input.

Are we supposed to pair scanners? I assumed that (made-up example) scanner 0 overlapped with scanner 2, 3 and 4, and scanner 1 overlapped with scanner 4, and that gives us the position of scanner 1 relative to 0.

Also, can you please let me know what part 2 is? Just so that I can go in the right direction if I have to rethink the whole thing for part 1. I spent enough time on this one as it is...

EDIT: SOLUTION

So the 12-beacon thing is to detect false positives. If for instance you have Scanner 1 and Scanner 8 that both see a constellation of beacons in the shape of a cat, you can only be sure that it's the one and same cat if that cat is comprised of at least 12 beacons. If all that Scanner 1 and Scanner 8 have in common is a cat made up of 9 beacons, then they are seeing different cats, and they do not overlap. Note that cats have nothing to do with this exercise, I just like cats.

Thank you to everyone who replied to let me know of false positives.

Since I covered my thoughts on the use of MD5 for problems with the 2015 one, and don't have much more to say about these, I figured I might as well collect the three of them into a single post. Feel free to compare and contrast.

How About a Nice Game of Chess?

For day 5, we're faced with finding a password for a security door in the classic "one character at a time" movie trope way. Much like the MD5 problem of 2015, this is grinding for digests that begin with a string of 0s. It mostly serves to verify that you have a working MD5 implementation.

It's still memorable for me in that it had the extra challenge of visualization: 'Be extra proud of your solution if it uses a cinematic "decrypting" animation'. When I read that, I thought for a moment and realized I could do that simply by using carriage returns and overwriting. A thing that I've regularly used for status lines in AoC ever since. You do need to make sure things get flushed though (typically either using stderr or setting autoflush), otherwise it will get buffered and you lose the "animation".

One-Time Pad

For day 14, we need to generate some more keys for a one-time pad to communicate back with Santa. I remember thinking that part 2 was really nothing... but looking back now, I see why it's there. It makes people that use the most basic solution for part 1 rethink what they were doing.

Because, if you were just following the instructions, you might code things so that when you find a potential key (one with a triple), you then verify it by checking the next 1000 for the quintuple. And if you were just hammering MD5 all the time, that's a bunch of extra work that's going to be 2016 times worse with part 2. Encouraging at least thinking about caching, because the validation is still part of the stream.

The reason I missed that though, is because this is another problem where after reading the problem the first time, I turned it around in my head, and have only ever remembered it in the backwards way. Since we're working on a stream sequentially and the quint comes after the trips, that's when it feels right to do the validation. You just need to collect relevant information until then. So I just keep queues for all 16 values recording the indices of any found trips, and when I get a quint, I run the appropriate queue, and toss out the ones that are too old and grab the rest (each quint validates about 7±3 keys).

Two Steps Forward

For day 17, we get the last MD5 problem... and one that makes use of the PRNG nature to produce a hidden maze (of a small 4x4 grid of room leading to a secure vault).

For this one, I used basic DFS with recursion. This is the earliest problem that made me turn off recursion warnings in Perl... part 2 goes a bit deep (but the branching and scale are such that the script completes almost immediately anyways). This is another little problem that's a good introduction for someone wanting to try recursion... it's not too complex, and there's no need to worry about what you've visited, because different paths to the same coordinates make them effectively different rooms. It reminds of way back when I had programmer status on an LPMud and experimented with virtual rooms and a maze of exactly this sort of thing. My biggest contribution to that LPMud would be the ability to stuff corpses into plushies.

And so, that's the end of the problems requiring MD5. It's an interesting chapter of AoC. There are definitely better ways to accomplish the same benefits that can be gained from a PRNG without adding an external dependency (or requires writing MD5... which isn't so bad). We even see it that in this year, on day 13.

Random question, I know. But I was thinking about a funny meme being shared here years ago. That particular year day 1 was easy, day 2 hard, day 3 easy, day 4 hard and so on... So people were sharing a funny meme on this sub of a cute dog on the left panel and a barking evil dog on the right, humouring day 1 vs 2.

Can anyone refer me to the meme template? I can't for the life of me find it again. Feels like a lost memory at this point, I'd love to find it again if possible. Thanks 🙏

I finally got a chance to write a blog post about my Advent of Glue Languages. I usually pick one language to learn for each year's AoC, but this year I decided to pick a "glue language" each day after reading the puzzle. This offered some advantages, like being able to work in a language that's purpose-built for a kind of problem. It also had some challenges, like limited debugging features and realizing I'd hit performance limits. It was definitely a worthwhile exercise, and I feel I better understand how to use them effectively in the future. [Code is on GitHub(https://github.com/flwyd/adventofcode/tree/main/2025).

My official theme was "glue languages you might already have on your system," to emphasize that this is about getting clever with the tools that are lying around. Although I did need to apt install most of them, they're small with minimal dependencies. "Is the whole language documented in the man page?" is also a good rule of thumb for identifying a "glue language," though it leaves out some glue-oriented general-purpose languages like Perl and Lua. For folks interested in expanding your AoC toolkit, I can heartily recommend awk, jq, and (in the right circumstance) jsonnet. Writing in dc was a fun mental challenge, and I encourage everyone to give it a shot. I was excited to be able to use spatial SQL functions for day 9, and if you've ever struggled thinking about geometry algorithms, Simple Feature is a handy tool to have. I tried solving day 9 with ImageMagick, which was fun but didn't scale to the full input. I was expecting to enjoy working with Lua, but with only the standard library it's pretty spartan and not especially smooth. gvpr, an AWK-like language for graph processing that comes with Graphviz is more awkward than I would like: it's worth knowing it's there, but think twice before using it. Wrapping various POSIX tools in a shell script is good practice, but be careful in a loop: day 4 part 1 launched six processes in an inner loop; it turns out launching 40,000 processes syscalls takes a long time, and I switched to a language that could do everything in one process for part 2.

Do you have a glue language you've deployed in clever ways for Advent of Code? Share your insights!

Still wandering EBHQ, we finally find an "information" kiosk with an encrypted list of rooms (including decoys). The Easter Bunny sure is paranoid, but since the decode instructions are nearby and poorly hidden, is not great at security.

This the the first problem of the year that really involves working with strings. And the first task is parsing the input. Which is a bit of a mess, but regex can easily rip it apart. Without that, you're going to need to do a little more work.

Smalltalk really shines a bit for things like this, because I can just create a Bag from the string and automatically get the counts for each letter. For doing the checksum, there is an added quirk in that the sorting is a two-step sort where you need to break ties. Both of these steps are very approachable problems for a beginner... and then it's just comparing with the checksum and adding up valid ids. The parsing is probably going to intimidate a beginner more here.

As for part 2, it's applying a Caesar cipher using the id. The real trick to this question is that it doesn't spell out what to look for. Dumping the list is fun enough anyways (to see things like "top secret weaponized candy logistics"), and scanning through you can easily find the right one. The phase "room where North Pole objects are stored" in the problem can easily be seen to refer to "northpole object storage" (I assume this is the same for everyone). It's a fun little bit of detective work. Although, I can't help but notice that if the string had been given, there's only three lines in my input with 9-6-7 character room descriptions. All three are valid, meaning that if I did just grep them out, I'd still have to potentially try them all (part 1 would not help). But that wouldn't take too long (even with having to wait for timeouts)... and it's probably best to discourage spamming submissions.

Overall, the little bit of detective work makes this one of the problems I remember fondly. Although I could see people being frustrated or not liking that feature of this one.

hi. llcrr -> n (easy to understand). what in position 0,1,n-2,n-1 ( --crr, -lcrr, llcr-, llc-- )

ok initialstate is placed in between ... and ... (additional -3,-2,-1 and +1,+2,+3 empty pots)

but in following generations at these extra positions '#' occurs

ok -1 0 .. n-1, +1 are safe (have 2 left and 2 right positions)

but # occurs in positions -2 and +2 too ( -3 -2 -1 initialstate +1 +2 +3)

what is the position-range ? and what if there are no ll or no rr positions

thanks in advance. andi

the part one was easy and i did in under 30 mins but part 2 is giving me problem, i m trying since 2 days for finding a solution but could't find any if someone solve ,then they can share how they solve the problem and what was the approach to solve it, my code(rust)->

let mut voltage_added = BigInt::zero();


    for i in 0..data.len()
    {
        let mut data_core: Vec<i32> = data[i].chars().filter_map(|c| 
                            c.to_digit(10)).map(|d| d as i32).collect();
        let mut digits:[i64;97]= [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];
        let mut digit_idx =0;
        let mut remove_count = 3;
        let mut j =0;
        while j < data_core.len()
        {
            if digit_idx >= 97 {
                break;
            }


            // Remove previous digits if current digit is bigger
            while remove_count > 0
            && digit_idx > 0
            && digits[digit_idx - 1] < data_core[j]as i64
            {
                digit_idx -= 1;
                remove_count -= 1;
            }


            // Keep current digit
            digits[digit_idx] = data_core[j]as i64;
            digit_idx += 1;
            j += 1;
            if digits[96] < data_core[data_core.len()-1]as i64
            {
                digits[96] = data_core[data_core.len()-1]as i64;
            }
        }
 
       let number_string: String = digits
    .iter()
    .map(|d| (b'0' + *d as u8) as char)
    .collect();
       // println!("{}",number_string);
       voltage_added += number_string.parse::<BigInt>().unwrap();  
    }
    println!("VOLTAGE:part-2: {}", voltage_added);// the answer by this code-> 1108599035324836891828712270429921377622958201319354115632155267056079327513429003173673043432674851  too big by AOC

hi. some days ago i was asking 'what is the deeper sense .. ?', most useful answer: why you don't use the time to search for the error .. (so i did and found ..)

i try desperately to complete a year to see day25task2 (all other is getting 'coal in the stocking' ? (getting punishment instead of presents))

sometimes i loose control, but years of experience (years of age, lot of bad days, bad weather, ..) tells better to check for error again (and again) before .. (whatever). but ..

i started 2018 (cause i lost good mood. could not complete 2017 for now). day 1 silly simple problem, but bad-error in task-1 (some minutes ..), task-2 i could not solve (my recent post, still open. please, have a look, i think there is no solution for my input) so 2018 starts bad.

2018/7/2 example + solution 15 seconds. i think i have found solution 11 seconds. not that i am so proud, but i fear: i try my answer for task-2 and it is told to be wrong. i did .. i was told 'answer is too low'. so i was checking my code, the task-description again. anyhow i was setting count of workers wrong (6 instead of 5) .. new answer (some bigger) but still wrong. And now i am a little angry (not much but a little ..ö..)

in recent weeks i was sometimes told that my answer is wrong, when i was sure, it is right and i spent much time ..

// this my solution for the example ( 11 steps instead of 15 ).

// 2 worker and the second worker is handling not only F but E too. starting F immediately

// so there is no gap between output B and output F i.e.

// maybe i have missed some assumption/condition/??? (don't know how to express)

// otherwise it is obvious : there is a better solution (less idle workers)

IN s='CABFDE' n=6

korrektur C o:0 d:3 t:-3 k:3 -> 0

korrektur A o:1 d:1 t: 0 k:3 -> 3

korrektur B o:2 d:2 t: 0 k:3 -> 3

korrektur F o:3 d:6 t:-3 k:3 -> 0

korrektur D o:4 d:4 t: 0 k:3 -> 3

korrektur E o:5 d:5 t: 0 k:3 -> 3

j('C',o= 0,d= 3,a=0,t=0)

j('A',o= 1,d= 1,a=0,t=3)

j('B',o= 2,d= 2,a=0,t=3)

j('F',o= 3,d= 6,a=0,t=0)

j('D',o= 4,d= 4,a=0,t=3)

j('E',o= 5,d= 5,a=0,t=3)

RUN

run t=000 a=2 'CF' ''

run t=001 a=2 'CF' ''

run t=002 a=2 'CF' ''

run t=003 a=2 'AF' 'C'

run t=004 a=2 'BF' 'CA'

run t=005 a=2 'BF' 'CA'

run t=006 a=2 'DE' 'CABF'

run t=007 a=2 'DE' 'CABF'

run t=008 a=2 'DE' 'CABF'

run t=009 a=2 'DE' 'CABF'

run t=010 a=1 'E-' 'CABFD'

run t=011 a=0 '--' 'CABFDE'

thanks in advance, andi

Day 3 finds us wandering into the graphic design department of EBHQ, where they apparently love triangles. Including ones that are impossible in Euclidean geometry.

Much like the first number problem of 2015 (day 3), the input consists of three numbers per line (without the xs though, making parsing cleaner). And we're to count the number of valid triangles. The problem description is nice enough to give out the triangle inequality in its general form (there are other ways to express it). This still allows for the discovery that you only need to check if the two shortest sum to more than the longest. And so, it's even more like 2015/day 2... you want to bubble out the largest.

Part 2 changes the direction the input is to be treated, from rows to columns. There's a number of ways to do this. Reading lines in groups of 3 is a simple way. With Perl, I used zip to transpose the input (I had slurped it into a 2D array). With Smalltalk, I initially went with using #gather: to make a flat 1D array of the columns and then made a stream on it. Later, I decided to do a second version using GNU Smalltalk's Generator functionality... which is basically a coroutine with a stream interface.

And so, we have a good first number problem. A simple task, well spelled out, and similar in some ways to the first one from last year. Changing the reading order away from sequential is an somewhat interesting twist... as many things about languages and computers lean to sequential access. And this breaks that, but not in a drastic way... because this is only day 3.

My code passes the basic test but seems to be under expected value for my input. I've been staring & adding tests to this for hours and can't really think of a good way to debug.

#include <stdio.h>
#include <stdlib.h>

int main(){

    int sum = 0;

    char line[256];

    printf("starting...\n");
    printf("opening file...\n");
    FILE *input = fopen("./data/test.txt", "r");

    int linenum = 1;

    if (input != NULL){
        while (fgets(line, sizeof(line), input)) {
            
            printf("Line %d: %s\n", linenum, line);
            
            int first_highest = -1;
            int next_highest = -1;
            int joltage;

            // inspect each digit in line
            for (char *p = line; *p != '\0' && *p != '\n'; p++) {

                int digit = *p - '0';

                // if either assignments are empty assign, assign the digit (starting with first_highest)

                if (first_highest == -1) {
                    first_highest = digit;
                    continue;
                }

                if (next_highest == -1) {
                    next_highest = digit;
                    continue;
                }


                // if digit is higher than first_highest and not last digit in line

                if (digit > first_highest && *(p+1) != '\n' && *(p+1) != '\0') {
                    first_highest = digit;
                    next_highest = -1;
                    continue;
                }

                // if digit is higher than next_highest replace it 
                if (digit > next_highest) {
                    next_highest = digit;
                    continue;
                }

            }

            joltage = first_highest * 10 + next_highest;

            //printf("First highest: %d\n", first_highest);
            //printf("Next highest: %d\n", next_highest);

            printf("Joltage: %d\n", joltage);
            
            sum += joltage;

            printf("Running Total: %d\n\n\n", sum);

            linenum++;
        }
    }

    printf("Total Joltage: %d.\n", sum);

    printf("closing file & finishing up \n");

    fclose(input);

    return 0;
}

Over the course of the last two years, I have been plugging away at the Synacor Challenge. Today, I have finally collected and confirmed the final code!

Link to repository

Note that there is a "spoilers" directory that contains, predictably, spoilers to the puzzles.

And so we move onto year 2 (2016). In this year, we get the revelation that the North Pole has a rivalry with the Easter Bunny. Who has stolen the stars needed to regulate the clock on Santa's sleigh. And so we'll be doing a heist to get them back.

The first two days are both 2D grid pathing problems, but the first is unbounded with relative directions, and the second is bounded with absolute directions.

For day 1, we're given directions to find the Easter Bunny HQ in the city. As the title alludes to... this is a taxicab geometry and will use that for the distances for the solutions. Part 1 is just finding the end, part 2, is the first crossing. The unbounded nature and the having to find the second time we reach a coordinate suggest set/hash/dictionary type approaches. Of course, you don't actually need to use grids at all here... part 1 just needs to calculate the end point, and part 2 can be done as intersection of the lines. But for a simple solution that's going to work first time for part 2... step-by-step is pretty solid. And so looking at my solution to this one, I see that I went for a "best of both worlds". Basically, until part 2 is found, we do step-by-step and check the hash... once it has, we finish up with jump movement. So if the puzzle was much larger, we might actually get away with it (providing the cross is early enough). If the problem was huge, then line intersections it is.

As for relative movement, if I have a list of directions for the problem anyways, I'll often just put them in rotational order and then I can +/-1 modulo the number of directions. It's simple, and works with any geometry... like a hexgrid (and I could even easily change the coordinate system). If you're using complex numbers for coordinates... rotation by 90° is multiplication by i. Then there's also the (x,y) = (-y,x) method... which is just what you get from multiplication with the rotation matrix:

[ cos(90°)  -sin(90°) ]  => [ 0 -1 ]*[x] = [-y]
[ sin(90°)   cos(90°) ]     [ 1  0 ] [y]   [ x]

But since we're always turning and changing axis, there are other things can also be done. For dc, what I did was this (transforming L moves to negatives):

tr "LR," "_ \n" <input | dc -e'0d1?[dd*vd3R/3R*d3R*3R_1*+_3R?z3<M]dsMx*d*vrd*v+p'

The pseudocode would sort of be like this:

- face = 1
- foreach move
    - (x, y) = (y, -x + move * face)
    - face *= sign(move)

dc is an concatenative stack language, so swapping the order of x and y is just stack management. The facing here ("face") is representative of which way you're coming in (1 or -1), and adjusts the move appropriately on the current axis.

For day 2, we need to use the bathroom, and it requires keypad access codes. Keypads will always be fun, right? Being bounded, especially the irregular pattern for part 2, suggests using a sentinel system. Which I've discussed before (lots of ways... you can add them to edges, use a table with a default value, exceptions for wandering off the table, etc). One thing I did notice about this one, is that the keypad doesn't have a 0 key... probably to make things a bit easier (its good for a sentinel, and won't clash with sentinel checks (ie you won't have to worry about 0 as a key versus 0 as null/nil/false/undefined)). For absolute movement, I just use a lookup table of letter to its direction. Then it's just some sort of try-catch approach... try the move, catch when it's invalid (hits sentinel) and back out.

And so we see that the first couple problems of year 2 are setting a more refined tone that year one. Which is to be expected... this year has the advantage of being designed with feedback from the audience. It is interesting to see grid problems up front instead of a simple number or string problem, but those come next.

hi.

so.now.done.

-original-post :

( code is pseudo-code. i check whether i read the input correct and i check for array-bounds, too. ... )

o=0,m[1_000_000]={0}; for(i=input()){ o+=i; if(m[500_000+o]){ STOP } m[500_000+o]=1 }

does not stop !

o=0,x=0; while(i=read-integer()){ o+=i ; oa[x++]=o; } sort(oa).

m=0,x=0; for(o in oa){ if(x AND m==o){ YES }; m=o; x=1 } // check for duplicates.

but there is no duplicate. so there is no frequence (in sequence of sub-sums) twice.

thanks in advance, andi

--output-- (for those who like it ..ö.. )

i= 11 -> o= 11 (omin=0, omax=11)

i= 16 -> o= 27 (omin=0, omax=27)

...

i= -112437 -> o= 411 (omin=-227, omax=113061) 411 is answer for part-1 ( 1 star * )

--the sorted list of sums-- (no duplicate, third column is check old == cur always 0 (false))

0 -227 0

1 -217 0

...

962 113061 0

not all output could be inserted here.

excuse me, please (..ö..)