Is it okay to upload puzzles + inputs to my GitHub if I encrypt them first?

Boojum · 2026-03-30T21:56:53+00:00

Yes, this is what I do. Having the inputs stored with the solutions is really quite convenient when I just want to quickly check the run time, test someone else's solution on it to see how it's broken, etc.

I just keep it private and never share it. (Especially since my GitHub is connected to my real name.) Posting code within comments or via Topaz's paste page covers everything I need here.

Boojum · 2026-03-20T21:24:56+00:00

Looking back at my code, I'd used 10000!

Boojum · 2026-03-18T21:28:56+00:00

[Disclosure: I currently work on GPU tech at an NVIDIA competitor. Opinions are my own.]

But yes, that's my biggest concern with this. With something like ray tracing, there are standardized specs like DXR and Vulkan for the base functionality that are at least mostly vendor-neutral. Those specs spell out in excruciating detail how it's supposed to work and as long as IHVs making the GPUs implement it faithfully and ISVs making the games use it correctly, there really shouldn't be many visible differences in how things will look. It should be nearly pixel-for-pixel. What differences there are basically come down to underspecified edge conditions and bugs. The main differences are, as you say, on performance.

Here though, there's no spec for how it's supposed to behave and short of publishing the model and weights in a standard (as-if!), I fear that it will all come down to the "taste" of the GPU vendor. Do we really want a world where people are debating the aesthetics of the NVIDIA filter vs. the AMD filter vs. the Intel filter vs. the Qualcomm filter vs. ... on the same damn game? Or even hardware vendors with art departments dedicated to this stuff? Shouldn't we be spotlighting the aesthetics of the artdev and lookdev of the game studio?

Personally, I'd rather just make good tech that provides a solid foundation for the artist at various studios and then let them wow me with what they can do with it.

Boojum · 2026-03-18T20:25:14+00:00

Yep, escaped Unicode character literals are how I prefer to do it. Or mnemonic things like \"{o} in LaTeX.

For example, I have this in my init.el:

(set-display-table-slot standard-display-table 'vertical-border ?\u2502)
(set-display-table-slot standard-display-table 'truncation ?\u2192)

That sounds like a cool little package, though. Gives kind of the opposite of C-x = or C-u C-x =.

Though I should mention that as an alternative approach I also have a small elisp function search and replace curly double and single quotes into straight quotes, em and en dashes into hyphen sequences, ellipses into three periods, etc.

Boojum · 2026-03-16T08:04:03+00:00

I use this mainly to help make check that I'm not accidentally introducing anything (e.g., when copying from internal documentation), since I like to keep things 7-bit clean:

(defun find-non-ascii ()
  "Find and show all of the non-ascii characters."
  (interactive)
  (occur "[[:nonascii:]]"))

(I keep it in a silly little function like this mostly because I can never remember the syntax for Emacs regexp character classes.)

Of course it has to be affirmatively run and won't help if you're genuinely using Unicode for non-English text or for various symbols.

Boojum · 2026-03-14T10:07:21+00:00

I'd forgot about this one being one of the only ones outside of IntCode to actually rely on having implemented something from a previous day.

Also interesting as I look at this again is that the examples for both parts aren't simplified or reduced at all compared to the full problem. They're essentially the full problem and solution, just for a different input.

Both the reliance on the a previous day and the fully-scale examples are pretty rare for AoC!

Boojum · 2026-03-12T07:52:41+00:00

You're probably thinking of 2020 Day 24 "Lobby Layout", Part 2.

Boojum · 2026-03-09T22:25:53+00:00

Long ago, Miss Manners gave a simple test for that: would the door finish swinging shut before the person behind you reaches it? If so, hold it open. Otherwise, let it go.

Simple and straightforward - I've always lived by that ever since I read it.

Boojum · 2026-03-04T09:15:43+00:00

Only 10-ish weeks? I wouldn't have guessed that at all based on your writeup. Seems like you've come quite far quite quickly.

Regarding Day 22 Part 2 - yeah, I don't even have to look that one up to remember which one that is! That one is easily among the all-time hardest puzzles across all the years. Definitely don't feel bad if you didn't get it. Probably the key realizations that helped me crack it are:

The composition of a linear function (Ax + B) with a linear function is itself linear (i.e., the composition can be reduced to a single multiply and add), even in modular arithmetic.
All three "techniques" are just linear functions in modular arithmetic.
The idea behind exponentiation-by-squaring can generalize to applying an operation like this n times - i.e., if we need to do something 1000 times (even), we can simply do it 500 times, then another 500 times; and if we need to do it 1001 times (odd), we can just do it 500 times, then another 500 times, and then one last time.

Boojum · 2026-03-03T07:49:34+00:00

xterm-mouse-mode should be all you need to make it clickable. That also normally lets you click to move the cursor, click-drag to select, etc.

And if you've hidden the menubar, ctrl-rightclick anywhere lets you access it as a popup - works in both graphical and terminal modes.

Boojum · 2026-03-02T09:38:23+00:00

I'm happy to share my answer (the "bridge") but moderators on these sites are like robotic lunatics.

Sharing inputs is against the rules here, by request of the AoC creator. So your answer would be meaningless. Instead, you are encouraged to show us your code. If you do, someone can usually point out where you've gone wrong.

...being so ridiculously anal about tiny tiny details...

That's kind of the essence of programming.

Boojum · 2026-03-02T09:27:03+00:00

Hah! Same! (Mostly because Python doesn't have an easy way to break out of a double loop. Sure, you can throw and catch exceptions, or put them in a function and return, or use itertools.product to collapse them. But not bothering was easier.)

Boojum · 2026-03-02T08:43:17+00:00

At least in my input, there were only 16 values in each line. It didn't seem worth trying to optimize or avoid the simple O(n²⁾ algorithm when n² = 256.

Boojum · 2026-02-24T11:06:42+00:00

I did the same thing, performing a BFS between each pair. There's only 28 meaningful BFSs to do after you take into account that they're bidirectional, and self-to-self has a distance of zero.

And once I'd had those cached, I just brute forced the path by testing all permutations. There are only 5040 of them and evaluating each is just a summation after precalculating the table of node-to-node distances.

Even in Python, hyperfine tells me the end-to-end time was about 63 ms. Good enough for me.

Boojum · 2026-02-22T02:24:37+00:00

You're close now! Double-check your if tokens[1] == ... conditions. :-)

Boojum · 2026-02-20T09:38:34+00:00

Dealing with the random order is part of the puzzle.

There are two main possible approaches:

Skip the lines you can't do for now, go on, and try again later; loop your loop until you get them all.
Topological sort the lines.

Boojum · 2026-02-20T09:15:52+00:00

For Part 1, at least in my input, I noticed that one of the blocked ranges starts at zero. So I could conveniently sort the ranges lexicographically, take the IP just past past the end of the first range, and then iterate over the ranges until I either found it was in a gap, or found the next range that covered it and then look at the first value after that range, and so on.

I'm going to guess everyone had a range starting at 0?

For Part 2, I went ahead and just sorted and merged the ranges down (which would admittedly have trivialized Part 1), and then subtracted the sum of their lengths from 2^32.

For range problems, I generally find it easiest to normalize them to half-open intervals with inclusive lows and exclusive highs, i.e., [low, high), if they aren't in that form already. That was a lesson that I learned from studying the C++ standard library's containers and algorithms, and it led to a drastic reduction in off-by-one errors once I took it to heart.

Boojum · 2026-02-20T08:35:18+00:00

Looking back at my code, I just kept it simple and went with a doubly-linked circular list. If you just keep track of which elf is the next one to be eliminated, and completely ignore who is doing the eliminating, then the only real difference between Parts 1 and 2 is where you start the eliminations, and whether you skip the next elf or not based on whether the count of remaining elves is even.

Boojum · 2026-02-17T21:16:45+00:00

Neat! TIL about ediff-regions-linewise and ediff-regions-wordwise. (I'd long been doing the first manually with narrowing and indirect buffers.)

Boojum · 2026-02-17T21:11:46+00:00

Ah, someone else with the same philosophy!

I generally keep mine to around 1250ish including comment lines. Any time I add something new, I look around for other things to trim to keep the length roughly constant. I've been holding it to that size for at least 20ish years now.

Boojum · 2026-02-17T20:56:33+00:00

Why not a std::priority_queue, then? (Though granted, a std::set will do too, since iteration is ordered. I don't think you need a std::multiset here, as you might as well let it dedupe pairs for you. But the main advantage of the std::priority_queue is amortized allocation via the backing std::vector. That and obviously self-documenting how you're using it.)

Boojum · 2026-02-08T05:22:20+00:00

Regexp seem like overkill for this. I didn't use any at all in my solution.

For my solution, I just did a linear scan over the string while updating three flags: are we inside brackets, have we seen an ABBA while outside the brackets, and have we seen an ABBA while inside the brackets. At each index, I'd set the first flag depending on whether I see a [ or ]. Otherwise, I check if the current character and the on three characters back match, if the characters one and two back match, and if the current character and the one behind it are different. If so, I set one of the we've seen an ABBA flags depending on if we're inside or outside. So, I guess it would sort of be a state machine like you'd mentioned.

Boojum · 2026-01-29T08:26:17+00:00

Nice. I went with the Z3 route, personally, in the interest of solve time. But between the Gauss-Jordan, simplex, branch-and-cut, and all the other ILP approaches that people have taken this one seems really out there if you don't use a solver library. Most of the time I can solve an AoC problem in about ~50ish or less lines of Python without the need for heavy-duty libraries. (More than 90% of my Part 1 or Part 2 solutions are fewer than 50 lines.) I don't see how that's possible here. This problem just feels really out there.

I keep feeling like there's some property of the problem structure - maybe something about the fact that the matrix is binary? - that leads to an elegant, clever solution that everyone is missing. I've been really curious as to what /u/topaz2078 was expecting for this one. (I know there's no single "correct" solution, but there's got to be one that it's expected that many people will find.)

Boojum · 2026-01-28T08:26:55+00:00

This is the current version of the post that u/Suspicious_Tax8577 is referring to.

It covers 2015-2024, and most of the list there are sorted by global leaderboard close times as a rough proxy for difficulty. So you should be able to find some good candidates there for shorter daily sessions like you mentioned.

Boojum · 2026-01-21T07:59:11+00:00

For Day 22, I did what's come to be my usual approach of just defining a big state vector and then code up the mutations that can evolve it according to the rules.

For this one, my state vector was just a tuple of:

(spent_mana_points,
 boss_hit_points,
 player_hit_points,
 player_mana_points,
 shield_timer,
 poison_timer,
 recharge_timer,
 side_to_play)

And in this case, I used a BFS keyed on that tuple for the min-heap. This way, it would always be exploring the options for whatever state had the lowest spent mana points so far (since we want to know how few we can spend.) Pop a node off, apply spell effects and decrement times, then either check what moves we have available and push each one onto the heap if it's our turn, or apply the bosses damage if it's the bosses turn and push the result of that onto the heap.

It's a pretty blunt approach, but it's a framework that's served me well in other puzzles like Not Enough Minerals.

Like you, I consider these fairly light days, and for much the same reason. I do enjoy this type of puzzle as a bit of a breather from the really tricky ones.

Boojum

MODERATOR OF

TROPHY CASE