hey y'all, i'm hyperneutrino, an AoC youtuber with a decent following. i've been competing for several years and AoC has been an amazing experience and opportunity for me. it's no secret that there is a big issue with people cheating with LLMs by automating solving these problems and getting times that no human will ever achieve, and it's understandably leading to a bunch of frustration and discouragement

i reached out to eric yesterday to discuss this problem. you may have seen the petition put up a couple of days ago; i started that to get an idea of how many people cared about the issue and it seems i underestimated just how impacted this community is. i wanted to share some of the conversation we had and hopefully open up some conversation about this as this is an issue i think everyone sort of knows can't be 100% solved but wishes weren't ignored

eric's graciously given me permission to share our email thread, so if you'd like to read the full thread, i've compiled it into a google doc here, but i'll summarize it below and share some thoughts on it: email: hyperneutrino <> eric wastl

in short, it's really hard to prove if someone is using an LLM or not; there isn't really a way we can check. some people post their proof and i do still wish they were banned, but screening everyone isn't too realistic and people would just hide it better if we started going after them, so it would take extra time without being a long-term solution. i think seeing people openly cheat with no repercussions is discouraging, but i must concede that eric is correct that it ultimately wouldn't change much

going by time wouldn't work either; some times are pretty obviously impossible but there's a point where it's just suspicion and we've seen some insanely fast human solutions before LLMs were even in the picture, and if we had some threshold for time that was too fast to be possible, it would be easy for the LLM cheaters to just add a delay into their automated process to avoid being too fast while still being faster than any human; plus, setting this threshold in a way that doesn't end up impacting real people would be very difficult

ultimately, this issue can't be solved because AoC is, by design, method-agnostic, and using an LLM is also a method however dishonest it is. for nine years, AoC mostly worked off of asking people nicely not to try to break the website, not to upload their inputs and problem statements, not to try to copy the site, and not to use LLMs to get on the global leaderboard. very sadly, this has changed this year, and it's not just that more people are cheating, it's that people explicitly do not care about or respect eric's work. he told me he got emails from people saying they saw the request not to use LLMs to cheat and said they did not respect his work and would do it anyway, and when you're dealing with people like that, there's not much you can do as this relied on the honor system before

all in all, the AoC has been an amazing opportunity for me and i hope that some openness will help alleviate some of the growing tension and distrust. if you have any suggestions, please read the email thread first as we've covered a bunch of the common suggestions i've gotten from my community, but if we missed anything, i'd be more than happy to continue the discussion with eric. i hope things do get better, and i think in the next few days we'll start seeing LLMs start to struggle, but the one thing i wish to conclude with is that i hope we all understand that eric is trying his best and working extremely hard to run the AoC and provide us with this challenge, and it's disheartening that people are disrespecting this work to his face

i hope we can continue to enjoy and benefit from this competition in our own ways. as someone who's been competing on the global leaderboard for years, it is definitely extremely frustrating, but the most important aspect of the AoC is to enjoy the challenge and develop your coding skills, and i hope this community continues to be supportive of this project and have fun with it

thanks 💜

People really need to take a step back and realize that when you've been doing algorithms problems for 10 years, your definition of "difficult" can wind up skewed. For example, I remember Day 12 from last year (EDIT: fences) as a comparatively easy BFS, where the hard part was just figuring out that trick where numCorners = numSides. But there were also people posting that day about how it was getting too difficult for them, and wishing the rest of us the best as we soldiered on. There's a reason that I'll frequently quip about how "easy" is a relative term when describing the stuff I do in tech to people.

But when half the posts in the sub are about how the problems are too "easy" this year, it's really just telling the people who are already struggling that they just aren't smart enough because these are supposed to be the "easy" challenges.

Like every year, around this time, I stop participating in AoC for two reasons:

1. I have too many other things to do with family and holiday shenanigans.
2. It gets too complicated, so I’ll probably solve it sometime next year—or maybe not!

Either way, I absolutely love these first two-ish weeks of this challenge and this community!

So yeah, just wanted to post some appreciation for this yearly event.

Best wishes and happy holidays to everyone!

I’ve been reading through the sub and I feel like I’m seeing an elephant in the room that not many people are discussing. It's about Eric’s decision to shorten the event this year.

For context, Eric wrote:

Why did the number of days per event change? It takes a ton of my free time every year to run Advent of Code, and building the puzzles accounts for the majority of that time. After keeping a consistent schedule for ten years(!), I needed a change. The puzzles still start on December 1st... and puzzles come out every day (ending mid-December).

I wanted to write this post not to complain, but to send a message full of empathy.

1. The Human Cost First, we have to acknowledge that Eric has kept a consistent, grueling schedule for a decade. Ten years is a massive commitment. It is completely understandable that he needs a change to protect his time and mental health. We should support that.

2. Why We Still Code (The Musical Analogy) There is a lot of talk about AI right now. Some might ask: "Why bother solving puzzles when an AI can do it in seconds?"

My answer is this: People still go to musicals and live concerts even though Spotify and streaming services exist.

We don't do Advent of Code because it's the "efficient" way to get an answer. We do it because we want to solve the puzzle. We do it for the thrill, the frustration, and the learning. There will always be people who want to invest time in solving puzzles without AI, just like there are people who enjoy musicals.

3. A Generational Tradition Advent of Code might be a niche, but it has a strong, beautiful community.

To Eric: Do not give up.

I see Advent of Code becoming a tradition as strong as Star Wars. It is something we pass down. You have already built a strong basis for following generations. My children are already wearing "Advent of Code" pajamas. They know about the event, and they are growing up with it.

Whether it is 25 days or 12 days, this tradition is important to us.

Thank you for the last 10 years, and here is to many more—in whatever format works for you.

What do you for work? Since we all made it this far I’m thinking we’re all pretty similar, so I’m curious to know what careers you have all chosen.

I’m asking because I’m looking to make a career shift to match my interests more; previously I worked as a full stack SWE but I was honestly bored out of my mind. I’d love a job where it feels more like AoC, but I have no idea where I can find something similar to this (if anywhere?!). I dunno if this is a dumb/obvious question, but to me typical software development is nothing like the AoC puzzles we’ve been solving.

So yeah, feel free to share what your job is and how it satiates the same craving that participating in AoC also does, and I will be eternally grateful <3

Last year I completed the AOC puzzles with Python. This time, I'm planning to pick up a new language, but I'm still not sure on which one, Go lang maybe.

I'm here to find out what language is everyone else planning to use this year.

Hey, this year I see a lot of somewhat negative comments about difficulty and stuff like that, I just wanted to bring some positivity and say thank you to Eric Wastl for advent of code. I discovered it in 2018 I think, I just had a very light background in programming and hadnt practiced in almost 10 years. I learned a lot through it, later it helped me learn Python that I needed for a new job ; this year I was not hyped about it, but I solved the first few days because why not, and now once again every day I look forward to having some free time for the daily puzzle. So again, thank you for the amazing amount of work you put into the advent of code every year !

Thanks also for the reddit memes guys, checking this place is the first thing I do after getting my two daily stars.

I know I will not score top 100. Im not that fast, nor am I up at the right times to capitalise on it.

But this kinda stuff https://twitter.com/ostwilkens/status/1598458146187628544

Is unfair and in my opinion, not really ethical. Humans can't digest the entire problem in 10 seconds, let alone solve and submit that fast.

EDIT: I don't mean to put that specific guy on blast, I am sure its fun, and at the end of the day its how they want to solve it. But still.

EDIT 2: https://www.reddit.com/r/adventofcode/comments/zb8tdv/2022_day_3_part_1_openai_solved_part_1_in_10/ More discussion exists here and I didn't see it first time around.

EDIT 3: I don't have the solution, and any solution anyone comes up with can be gamed. I think the best option is for people using GPT to be honourable and delay the results.

EDIT 4: Another GPT placed 2nd today (day 4) I think its an automatic process.

Okay, a little dramatic title, and I am sorry for that. I don't know what I am expecting out of this post, some helpful encouragement, troll comments or something entirely new, but this was the first time I attempted to do AOC.

And it failed, I failed, miserably. I am still on day 15 pt-2. Because I couldn't be consistent with it, because of my day job and visiting family. But even with the 14 days solved, I still had blockers and had to look for hints with Part 2 of atleast 3-4 days.

I have been working a SWE* for 2 years. I hardly use any of the prominent algorithms in my day job AT ALL, and hence the astrix. I have been trying to get back into serious coding for past 6 months. And even after that, I can barely do 2 problems a day consistently (the aoc).

It just made me feel bad that all my 6 months work amounts to almost nothing, especially when compared to other people on this sub and around the world who claim the 2 parts are just with and without shower.

As I mentioned I don't know where this post is going and what I want out of this. But just felt like sharing this. Maybe you guys can also share your first aoc experience as well, or maybe you can troll the shit out me, idk. 🥲

TL;DR : OP is depressed because he's a shitty coder, claims to be a software engineer (clearly not), and shares how he could barely do 2 AOC problems a day without looking for a hint. You share your first AOC experience as well.

Please don't make frequent automated requests - avoid sending requests more often than once every 15 minutes (900 seconds).

I've already had to ban a bunch of IPs for sending requests too quickly.

If you are sending AoC traffic, you are responsible for making sure that traffic is appropriately throttled. Yes, even if you're using someone else's library or software to make the requests. Yes, even if your code misbehaves because it has a bug.

Please include a way for me to contact you, the person sending the traffic, in the User-Agent header of the request. If you provide a library or other software that other users might use to generate lots of requests to AoC (like things that interact with private leaderboards), please ask the user of the library to specify their contact info so you can put it in the User-Agent header on their behalf. It doesn't usually help me when your library sends the library author's contact info (unless the library it itself misbehaving, which is rare, but include the name of your library in the User-Agent too just in case so I can find the library author's contact info too).

Okay thanks! Have fun this year! <3

OK, so I just got one star so far this year. It's 6:40 pm on December 23rd.

I am a beginner coder. I was fascinated by Java for a few months back in 2021. I was doing the AoC together with a very talented friend, who helped me with my Java code. Obviously he was a Python engineer. I enjoyed having something like this to share with a friend.

My friend died, only in his forties, in 2023. From a heart disorder he never knew he had.

I miss him.

I can't code to save my life. I forgot everything. But I try to do at least one puzzle to honor his memory every year. Last year I wasn't able to. But at least this year I could.

Sorry that this got morbid. So far no luck with part 2 of the puzzle though.

And my answers sure are ugly. But....I'm getting the answers!

This is super challenging, and for some reason, I'm choosing to not use any thing other than the core python libraries to do this. I doubt that's a winning strategy for future challenges. However, I've learned a little regex and list comprehensions. And probably a lot of other stuff. This is rad, and your memes are ABSOLUTELY KILLING ME. I don't know how this community can be so smart and so incredibly funny.

Cheers nerds!

EDIT: I made a curse word and I'm sorry.

With the parts factory up and running, we turn to building a lagoon to store lava for it. This involves an odd set of instructions for the digger with colour codes for the edge of the trench along the way. The surprise for part 2 being that the colour codes are actually the dig instructions.

And so we get a rarity in the input... it's really just 2 inputs packed into 1, as there's no attempt at overlap. The input for part 1 isn't scaled up, it's completely replaced (with the part 2 input having to be unpacked... it is effectively a binary file to part 1's text file). The input is extra nice in that it alternates between vertical and horizontal moves, even though it doesn't use relative turning instructions, but absolute directions on the 4 cardinals: U, D, L and R.

Not knowing what sort of problem the colours were going to add, my initial approach was to do a quick solution to see it, and so I did what I did with lava year in Boiling Boulders. A built my polygon and flood filled a box around it and subtracted to get the area.

Then part 2 reveals that the colours aren't colours and there isn't some weird task involving them... we just need to be much bigger. And that's how you nudge me to using Shoelace and Pick's. Shoelace is easy for me to remember as the name is suggestive of what you're doing... it's using the property that the magnitude of the cross product is the area of the parallelogram made with the vectors (but we just want the triangle between them, so it gets cut in half). So that's just successive cross products:

foreach my $i (0 .. $#vertices - 1) {
    $area += $vertices[$i][0] * $vertices[$i+1][1];
    $area -= $vertices[$i][1] * $vertices[$i+1][0];
}

A bit of cut and paste there to help make sure it looks right, but that's what cross product looks like in the plane (which is like we're lacing with cross overs). Saving the division by two for after, so this is twice area.

Pick's is something I hadn't used in a long time, so I didn't quite remember it, other than it was something simple involving area and perimeter. So I looked it up to make sure I got it right. With the problem being orthogonal on the lattice points, if I hadn't I might have forgotten that it isn't the perimeter, but the number of integer points on it. Also it needs to be adjusted for what we actually want (we want I and B):

# Pick's formula: I+B = A + B/2 + 1 (but still needed to halve the Area from Shoelace)
say "Part 2: ", (abs($area) + $trench) / 2 + 1;

I suppose given the nice orthogonal nature, you could also reasonably pull off a scanline approach, but you'd need to convert the representation of the polygon. You'd need to figure out what's an inside range, which we did a few days ago (when we could also have used Shoelace and Pick's).

But since there's a simple function to solve this, that makes dc a good option and so I did that:

cut -d' ' -f-2 /tmp/input | tr 'RDLU' '0123' | dc -e'0d?[r2~2*1-r2*1-3Rdlb+sb*d4R+_4R*rd_3R*la+sa?z2<M]dsMxlad*vlb+2/1+p'

perl -pe's/.*([0-9a-f]{6})./\U$1/' /tmp/input | dc -e'16i0d?[10~2~2*1-r2*1-3Rdlb+sb*d4R+_4R*rd_3R*la+sa?z2<M]dsMxlad*vlb+2/1+p'

Note that first I need to get rid on non-numbers, and convert the directions for part 1 (and I used the part 2 ordering there). So the code is largely the same, except part 2 works in hexadecimal (16i sets the base of the input), and needs to rip off the low nybble for directions.

But the real fun here is with the loop to do Shoelace, where we take advantage of the alternating horizontal/vertical property of the input with a bit of stack manipulation: x and y are both on the stack during the loop (which actually a tail recursion), and if we process them in the order they are on the stack, they naturally end up in reverse order. And so we naturally get them to swap roles each loop... thus alternating horizontal and vertical movement with the same code. This is one of the reasons I like stack languages.

Because my wife had a baby!

Though I have to say it's nice to see that it's down to 12 puzzles this year. Coming back to solve this later, when I have the time and am not heckin sleep deprived, will seem a lot less daunting now.

Pre-thank you to AoC's creator and all those that help support this labour of love. Y'all are amazing and what you do every year for this community, your time and continued dedication, is not only greatly appreciated, but warms my heart and fills it with Christmas spirit every year!

I hope everyone participating has a blast, and I look forward to catching up. (I'll be avoiding the sub because spoilers)

Have a wonderful, and hopefully somewhat less stressful, AoC and a very Merry Christmas season to one and all!

Firstly, on behalf of all my friends and colleagues who also do AOC, a big thank you to Eric. AOC is simply the most elegant, funny and creative coding challenges I have ever come across. I find myself constantly in awe of Eric's work - when I am struggling through a problem, he is operating of a whole other level, creating these problems and generating different input data etc. It is also so impressive the way AOC caters to literally every level of programmer out there, from beginner to seasoned dev. AOC is always part of my recommendation when others ask me how to get into programming.

Amid all the noise of our weird modern world, especially in the programming space, I find AOC is a great way to reconnect with my simple love of programming and problem solving.

I also wanted to comment on a few changes I noticed in AOC 2025

1. There is no global leaderboard in 2025
2. There will be 12 days instead of the usual 25

For details, please see https://adventofcode.com/2025/about#faq_leaderboard

Congrats to Eric on making these changes

1. If you read the link above, the global leaderboard was clearly causing many issues and people were losing sight of the spirit of AOC. I love the bold move to simply remove it. I wish Product Managers I have worked with in the past had the guts to make decisions like this.

2. Everyone has a limit and kudos to Eric for recognising his and making required changes. I 100% prefer having 12 days of AOC rather than no AOC at all.

Also, to those who are smashing the AOC API, pls take a chill pill. This is why we can't have nice things!!!

Tldr: Eric, you're a legend, thank you, let's all enjoy another year of AOC

So another year and another Advent of Code. I finished within the time frame. Possibly the first year I've done that? Usually the 24th and 25th I can't get to till after Christmas, often to the new year.

I really enjoy the challenges and I additionally use them as training with my junior engineers especially about understanding the problem, capturing the requirements and business rules, designing and more importantly communicating a thoughtful solution and then implementing it. I look at my skills going through my historic repos grow over the years, I doubt the level of problem solving skills would be anywhere as near developed without Advent of Code.

This year I learnt about z3 (even though I didn't actually implement in any solutions) and other SMTs. More importantly though I know I'm going into Christmas with my very young family knowing I won't be thinking about some problem on what is obviously a very important time for families. The balance this year gives for people like me cannot be understated.

Thank you Eric for all the hard work you do. I look forward to the future challenges.

The mirrors were pointing at a parabolic reflector dish which is probably used to heat the lava. And which also has its mirrors in disarray. There's a system involving a platform and rolling rocks to align things by tilting, spinning, and deforming. We need to spin it to get the rocks to the edges of the platform, but want to make sure that the structure can bear the load.

And so we get a 100x100 grid with three values... in addition to empty (.) and solid block (#), we have rolling rocks (O). Part 1 just requires tilting it north and calculating the load after the rocks stop. And for my initial solution, I didn't actually bother moving the rocks... I just used a state machine in the direction of travel for each column. The idea is simple... count Os, and when you get to a #, add the difference of triangular numbers to the answer (and reset the counter). Because all the rocks in that section roll to the top (which is the direction of scoring increase), so the score of them is the big triangle of the top rock minus the triangle under that train of rocks:

for (my $y = $#Grid; $y >= 0; $y--) {
    if ($Grid[$y][$x] eq 'O') {
        $count++;
    } elsif ($Grid[$y][$x] eq '#') {
        my $h = @Grid - $y - 1;
        # difference of triangles: [h(h+1) - (h-c)(h-c+1)]/2
        $part1 += ($count * (2 * $h - $count + 1)) / 2;
        $count = 0;
    }
}

I was clearly thinking of doing this in dc (this solution is designed to be simple to implement), and did do part 1 later:

perl -pe's/(.)/$1 /g;y/.O#/012/' input | dc -e'?zdsn[d2r:a1-d0<I]dsIx+[[zd;a3*3R+r:az0<L]dsLx?z0<M]dsMx[lc1+sc]sC[rdlcd3R2*r-1+*2/ls+ss0scr]sSln[d;a0r[3~d1=C2=Sr1+rd0<H]dsHx*+1-d0<I]dsIxlsp'

My notes pointed out that I wasn't feeling well that day, so this was done quickly. That probably also explains the lack of a Smalltalk solution on this day.

Part 2 is the classic scale up... do a full spin cycle (all four directions in NWSE order) one billion times. My initial solution for this used the Vector class and did the above state machine. Clear Os when you count them, backfill when you hit a #.

And then we need cycle detection (standard find the loop, use that with some modular arithmetic to get the answer). And for a quick answer at first, I just used the load score function, and to be safe I looked for a duplicate cycle (not just the first repeat, but two repeats of equal size... 2 points is a line, 3 is pattern). And I did double check that the numbers were also the same in the two ranges for added safety (not actually needed for my input). Then I used dc to do the calculation for the index and copy-pasted from the script output to submit. I later wrote the code to do the calculation, and also did a perfectly safe version (that's actually just as fast), using a massive hash key of the positions of all the rolling rocks (so no question that the first repeat is a cycle). As I wasn't feeling well, this one got left in that state.

Coming back to it, I saw it ran in over 20s. And figured that was mostly Vector overhead (it was worth for quick coding at the time). And sure enough, it's an order of magnitude faster without it. Playing with it further, I decided to reverse the state machine... run it the direction opposite the motion. The only reason I did it the other way was the convenience for part 1 and dc. The backwards state machine is about 9% faster... it doesn't have that backfilling loop. Instead, if works like this:

for (my $j = 0; $j <= $Size; $j++) {
    my $tile = $Grid[ $x[0] ][ $x[1] ];
    if ($tile == 1) {
        $pos[$mdim] += $mdelta;
        $Grid[ $x[0] ][ $x[1] ] = 0;
        $Grid[ $pos[0] ][ $pos[1] ] = 1;
    } elsif ($tile == 2) {
        @pos = @x;
    }

    $x[$mdim] += $mdelta;
}

When we get to a # we set pos to it to know where to roll rocks to. Then when we find rocks, we increment that and move the rock. For a tiny extra boost, I also switched to an (axis, delta) pairing for the vectors instead (x,y). There's still more that I could have done, especially with scoring and hashing. But this is good enough for now... how often does this load need to be calculated?

Last year I did all 50 stars for the first time, then went back and did 2015-2017 and some of 2018, reading the reddit here in parallel - those old days were glorious. Was greatly looking forward to starting 2025 on Dec. 1, and was a bit disappointed to read the "12 days" announcement, but fine, it was totally understandable.

Days 1 and 2 were normal but somehow today, Day 3, when I read the word "joltage", I don't know, I just .. stopped. The silly jokes, the elves and their "technology", the green-black matrix we get to live in, the Christmas tree, the whole .. universe ... is incredible. Along with this community to meme every single problem.

Today, I felt really sad.

What Eric has created here is so special. I'm very grateful for the 10 prior years, that I still have 2018-2024 left to finish, and however many 12-day years he has left in him - even if this one is the last - are enormously appreciated. Thank you.

Heading towards the "Hot Springs", we arrive at an observatory. And the Elf there will show us the way, after we help with his analysis.

And so we get what appears to be a 2D grid problem. My input is a 140x140 grid of mostly empty space (.), with 450 galaxies (#). We want the sum of distances (Manhattan) between all the pairs. But as is the case with astronomy... you look at stuff at billions of light years away, but that's was where and what it was like billions of years ago. It's now much further away due to expansion. And so we need to work that out. And the rules given are that any empty row or column becomes twice as big.

And I guessed that part 2 would be making things bigger in some way. So to see what that was, I just brute forced part 1 to begin with. I was experimenting with the Math::Vector::Real module for handing points and vectors at this time, and it has some overhead, but if the task isn't too bad (and this one isn't), it can make up for it in simplicity of coding and legibility. One nice thing is that the constructor is short and simple: V(...). Another thing is that it has built in distance functions (and this was an opportunity to use one). The one problem I have with it is the print string... I'd rather have it plain and using $;.

So it was very easy to just do the thing... shift the coordinates, and double-triangle loop the pairs:

my $dist = 0;
foreach my $i (0 .. $#shifted-1) {
    foreach my $j ($i+1 .. $#shifted) {
        $dist += $shifted[$i]->manhattan_dist( $shifted[$j] );
    }
}

And since part 2 only made the gaps bigger, I had another really fast turnaround by just changing the scale factor for:

$g += V($yshift, $xshift) * $scale;

At which point the script ran equally fast to part 1 (there's no additional work), which was an immediate answer. I suppose after the pipes and interpolation on the weekend, this is a break Monday. Because it really didn't force things to be better. What did that for me was deciding to do a dc version (and I did Perl and Smalltalk versions from that). I do have a bigger test case (280x280 with 5000 galaxies) that someone posted at the time to help prompt people to do that as well. That one makes my brute force take a minute and a half.

But for me, I was thinking while doing the brute force, and it was not lost on me (while thinking of tricks that might be needed for part 2 scale-ups) that Manhattan distance makes the x and y parts independent. Which is the point I decided to definitely do a dc solution... because with that realization, the problem turns from 2D to 1D. Basically, the grid can be collapsed to lists of row sums and column sums, and then discarded. And short lists of numbers to chew on, that's something for dc.

The other thing I thought about was that getting the sum of absolute differences of all pairs is a typical programming test problem. And it's largely the same sort of math I was working with on day 9 as well. The trick here is that a little algebra can collapse things into multiplication and make things a single loop.

For example, consider the list 2 3 5 8, and we want the sum of the absolute differences of the pairs. As a table:

    2     3     5     8
2   X   (3-2) (5-2) (8-2)   2 is subtracted 3 times             = (0-3) * 2
3   X     X   (5-3) (8-3)   3 is subtracted 2 times and added 1 = (1-2) * 3
5   X     X     X   (8-5)   5 is subtracted 1 time  and added 2 = (2-1) * 5
8   X     X     X     X     8 is added 3 times                  = (3-0) * 8

So there's a pattern in coefficients: -3 to 3 by 2 (where those 3s are the #numbers - 1).

Of course the problem is a little more that that here... as we have a multiple of the numbers at each step (number of galaxies in that row or column). But it's not that hard to work out the adjustment to do that as well. The end result (as an extension to Array) in my Smalltalk solution is:

diffSum_expand: scale [
    | col seen sum number |

    number := self sum.
    col := seen := sum := 0.
    self do: [ :count |
        col  := col + ((count = 0) ifTrue: [scale] ifFalse: [1]).
        sum  := sum + ((2 * seen + count - number) * count * col).
        seen := seen + count.
    ].
    ^sum
]

And the dc (which still isn't fully golfed):

perl -pe's/(.)/$1 /g;y/.#/01/' <input | dc -e2 -e'ss?1[0[3Rd3R+rz2-d_3R;c+r:cz2<X]dsXxdlg+sgrd_3R:r1+?zRz1<Y]dsYx[ls*]sE[0sc0sa0r[dlAxd1r0=Elc+scddla2*+lg-*lc*rla+sa3R+r1-d0<L]dsLx+]sD1-[;r]sAdlDx[;c]sArlDx+p'

Change the -e2 to -e1000000 for part 2 (or whatever scale you want).

So this was another really fun day.

I've noticed I often see the same languages pop up when looking at AoC solutions (JS, C, Java, Python, ...), and as a Lua user myself I'd love to know if any of you use any less heard of languages.

Edit: bonus points if you use an esoteric language.

Gliding up to metal island we find signs for "Hot Springs". Which we will see in a couple days, because decide to go there for directions. We also notice that everything on this island really is metal, including the plants and animals. One of which runs into a pipe that makes one big loop (not a maze at all)... although there are a lot of separate pieces of pipe lying around, making the input a real mess of ASCII art.

My input is 140x140, the use of L7FJ for right angles along with |- for the straights, plus the extra bits lying around, does not make this easy on the eyes. Fortunately, we're writing code to look at it for us instead (I suppose you could print it out and do it by hand... but the loop is over 13k in my input). Looking for . in the image, I see that those are mostly around the edge, although there is a circular area in the middle with a bunch.

Part 1 wants us to find half the length of the loop. Part of the fun of this is that starting location is covered with an 'S' and we need to solve the underlying pipe there. Building a table of the pipes with their exit directions not only does this, but it helps with quickly moving around the loop. Because when we move in a direction we know where we came from, and so we just immediately use the other direction to leave.

Part 2 is where the fun begins. Part 1 is useful for it because it tells us what pipes are in the loop so we can remove/ignore the others... because we want to know the amount of tiles enclosed by the loop. Telling if something is inside a polygon was one of the first tasks I had as programmer... it was the task that also involved the 2D cross product stuff I used for asteroid shooting on 2019 day 10. For that I was counting the number of crossings from the point until "infinity" (the bounding box). But on this day, I decided to save that for the Smalltalk solution.

And that Smalltalk solution is pretty simple because of that. It's basically a scan of the grid after part 1 finds what's not in the loop. You start outside, and every time you cross a line of the loop, you toggle that. Any squares you run into when "inside" you count. There is one potential case to look out for, and that's travelling exactly along a line... in which can you'd only toggle if the segments some in from one side and go out the other. There's a little trick that can be used for that, of pretending to be slightly off center (not being exactly on the line, you end up crossing 0, 1, or 2 times and it works out)... and with discrete tiles, we can definitely use that (no need to be anywhere in particular in the tile). In my case, I chose to be a little above center (and so it was L, J, and | I cross; F, 7 and - I slip over top of):

(chr = $|) | (chr = $L) | (chr = $J) ifTrue: [inside := inside not].

For my initial Perl version though, I figured that since it's the more friendly language, I'd be a bit fancier. I like doing Nikoli pencil and paper puzzles... there's lots of different kinds, and some of my favourites are the ones with the invariant that the solution be one big loop (things like Slitherlink and Masyu). And when doing these, I like to colour the inside of the loop as I go. Because as you walk around the loop, if the inside is on your right, it's always on your right (unless you turn around and walk around the loop the other way). And so you can tell which side is outside at the edge, and lightly shade the inside and propagate it. When two lines are approaching in the middle, this gives important clues on how you can hook them up (plus it makes the solution look like abstract art at the end).

And so I decided to use that property, because I just think it's cool (and it would be different). Basically, I create a list of tiles to the right hand side as I walk around for part 1. Then I flood fill from each of those... the outside being guarded by two rings of sentinel . and ~, because we don't know if RHS is the inside yet. All we know is that when we get to the end, we can check if a known outside point on the edge (in the . sentinel ring) got hit by the flood fill. If so we output $count - $rhs_count instead because we filled the outside. It's sort of like the lava droplet of 2022 day 18.

I recall that some people did this type of flood fill approach by doubling the grid, so that the narrow paths become real paths they easily could flow through. With that you can start your flood fill from a known outside exactly like the lava droplet. And I'm sure lots of people also did counting line crossings, because that's a really standard approach to this sort of thing. But I don't think many people did what I did for my Perl solution. Which is part of why I did it.

The story this day is that we need to print a bunch of manuals, all consisting of a small number of pages from a master list, but there are also lots of rules about the printing order between pairs of pages, stating that if <N> and <M> are part of the same manual, N must always be printed before M.

Before the list of manuals to print we have a long list of these rules.

We know that for any given manual with its list of pages, these rules lead to a single unique legal ordering.

However, it is both possible according to the rules, and as far I know, also true that:

There exist at least one ring of rules (A<B, B<C,...X<Y,Y<Z, Z<A), which means that there cannot be any complete ordering of all the pages, so the order has to be determined for each set of manual pages, otherwise we could just have sorted the page numbers once and be done with it.

In Perl it felt natural to store these rules as hashes, each possible page number from 1 to 99 gets a list of the pages it must be before or after.

The code ran in 5.5 ms so fast enough for an interpreted language.

In my Rust version I noticed that 100 pages is less than 128 so I stored those lists as u128 bitmaps, this allowed all the checks to be done with logic AND operations.

For Part1 just iterate over the pages:

    fn is_ordered(&self, pagelist:&Vec<u8>) -> bool {
        let mut prev = pagelist[0];
        for p in 1..pagelist.len() {
            let curr = pagelist[p];
            if self.pages[prev as usize].infront & (1 << curr) != 0 {
                return false;
            }
            prev = curr;
        }
        true

If there is no rule for prev vs curr then that implies any ordering is OK for that pair of pages.

Part2 is a little bit (grin) more complicated, but the same bitmap logic determines which page must be first, second, third etc.

I start by generating a pagelist bitmap, with 1 bits for each page in that particular list, then I iterate over the pages, from the end forwards, until I find a page that has no other pages behind it (i.e., its "behind" bitmap ANDed with the pagelist bitmap is zero).

This page can then be exchanged with the original last page. After placing it, I remove it from the pagelist bitmap, step forward one position and repeat the process until all pages are ordered.

Total runtime was 10.867 us (average over 1000 runs) vs the 18 us given by u/maneatingape, so more than fast enough for me.

(While writing this I realized that I only needed one of the two bitmaps per page, that would have saved a little bit of the setup time, as well as 1600 bytes of memory, but since the total working set is less than 4kB, everything fits easily in $L1 cache.

I thought this was an interesting puzzle, with some similarities to classic problems like managing free space in a file system using bitmaps.

PS. I am posting this just before 0100 Oslo time on Oct 5th, I'll keep the tradition going as long as I can or until u/musifter returns!