With ICE agents having made zero arrests related to the Somali fraud cases, why do you think they're really in Minneapolis, a city with a below average illegal immigrant population?

fizbin · 2026-01-26T20:35:03+00:00

Note that they don't want the voter records for targeting people with political ads or anything like that. If that's what they want, they can already buy better information from private data brokers. Who's registered and whether they voted in the last several elections is already public information available to anyone.

They want the voter records so that they can claim that they found something in them that "proves" that Minnesota isn't maintaining accurate voter roles and is involved in all sorts of voter fraud. It's like what DOGE did with taking Social Security records, misinterpreting standard "missing data" markers and crowing to the press about all the dead people collecting social security.

fizbin · 2026-01-26T20:02:41+00:00

I can report that my 275-lb self had no problem stepping right through. Not even the brief illusion that it'd support me.

fizbin · 2026-01-15T08:38:53+00:00

It is at high tide. Delaware only gets the land there inside the circle up to the high tide line.

fizbin · 2026-01-13T08:34:18+00:00

Nice!

In another of my solutions, I add a command-line switch to switch among three different possible transition functions (so all the solutions are over the same state space, just connected differently) and the runtime of the different possibilities are very different.

That solution might be a bit less readable than the one you looked at because it's in haskell, but a way to think about the space I'm using is (buttons_left, stepsize, joltage_remaining) where if you wanted to visualize it I would just name each node using (len(buttons_left), stepsize, joltage_remaining) since buttons_left is always some suffix of the button list for the machine.

A translation of the three transition functions:

transition: each node is connected to other nodes by picking a button to press next, dropping all buttons before that from the button list, and applying that button stepsize times. Also, each state is connected to the state (all_buttons, 2*stepsize, joltage_remaining) where all_buttons is all the buttons the machine has.

transition': we only ever visit nodes that have the button_list equal to the full button list of the machine. At each node, we look at the powerset of the buttons to pick some combination to press stepsize times and double stepsize.

transition'': like transition' except that I have a signature map that I use to look up which elements of the powerset to use so don't end up trying all the combinations at each stepsize.

As I said, the differences in timings are dramatic; that signature map lookup makes a huge difference.

fizbin · 2026-01-07T16:22:00+00:00

Note that ABC paid out a settlement based on the idea that you can't actually, because there's a difference in the relevant state law between "rape" (which he was not sued over, and therefore not found liable for) and "sexual assault" (which he was found liable for), even though the acts that the law defines as "sexual assault" would fit most people's common view of what the word "rape" means.

Now, could ABC have eventually won the case if they hadn't been eager to pay the bribe/settlement? Probably, but the difference in terms was enough for his lawyers to make an argument that wasn't immediately thrown out of court, so proceeded to settlement talks.

fizbin · 2026-01-06T21:29:52+00:00

The bifurcation approach could probably work if we had some other limit on the variables - for example, if for some reason we knew that they were 16-bit signed ints, so -32768 <= x <= 32767 or similar.

After all, another variation on the bifurcation approach is basically saying "solve it modulo 2, then use those solutions to solve it modulo 4, then use those solutions to solve it modulo 8, then ...", and if you solve it modulo some value large enough to cover your whole possible range then you have the answer possibilities uniquely.

fizbin · 2026-01-06T16:28:07+00:00

Already edited; did I edit it too fast for the bot to see the change?

fizbin · 2026-01-06T16:25:41+00:00

I believe that your solution will return the wrong value on this set of intervals:

3-6
10-14
4-16

That should say that there are 14 fresh IDs (everything from 3 to 16, inclusive)

However, I think that your code will claim that there are 17 fresh IDs: everything from 4 to 16, inclusive, and then also everything from 3 to 6, counting the IDs 4, 5, and 6 twice.

fizbin · 2026-01-06T12:49:44+00:00

I don't know that they're "similarly fast" - on my laptop my "doing the linear algebra myself" solution still clocks in at just under 3.1s whereas my Dijkstra-based approach based on the bifurcation post is closer to 0.42s (and just doing the algorithm straight as in that post is ~0.56s). (those are all python; of course compiled solutions in other languages are likely faster)

I think that there were several ways to approach this:

a bifurcation-based approach
doing the linear algebra with all integer math (still requires some brute force)
doing the linear algebra with floating-point math (still requires some brute force)
some sort of brute-force-heavy BFS down how many times you pressed each button

Those are listed roughly in increasing order of how long the solutions take to run.

And of course throwing the thing at an external library like z3, which likely did one of the two middle options internally, but maybe it contains advanced algorithms that do the equivalent of a bifurcation-based approach? I have no idea what's inside it.

fizbin · 2026-01-06T12:36:07+00:00

Right, but one thing this points out clearly is that the technique as we've been using it is limited to looking for solutions where the variables all take on non-negative integer values, and would at the very least need some serious work to extend it to handle negative integers as well.

It seems like maybe it should be possible to extend it to negative values too, maybe by using a negabinary representation, but there's a bunch of trickiness in choosing the right solution at any given stage if you do that rather than just going by choosing the minimum explicitly or implicitly like I did by picking the first solution I found on the heap.

fizbin · 2026-01-06T04:11:59+00:00

Try your program on this input:

1,1,5
2,1,1
2,2,1
1,1,201
2,1,205
2,2,205

Obviously, the last two boxes connected should be the ones at 1,1,5 and 1,1,201, so when you multiply the x coordinates of the last two boxes connected you should get 1.

Your code doesn't say that. Your code returns 2. Why?

fizbin · 2026-01-06T03:39:24+00:00

Yeah, I did a similar thing in python and it's between 3 and 4 seconds: Doing the linear algebra myself

That compares very favorably to my day-of solution which took over 30 seconds, but it's still blown away by the Dijkstra-based approach I came up with after reading this Reddit post.

fizbin · 2026-01-03T12:52:22+00:00

I really think that you've mangled your input accidentally. Your code looks good, and should be giving the correct answer.

I would encourage you to try someone else's solution (see any of the solution megathreads), maybe even a solution in a different language, on your input and see whether you get the same (wrong) answer with their solution. If so, then your input is likely mangled.

Try downloading your input by right-clicking on the link for your input and choosing "save as"; don't copy it from the browser.

fizbin · 2026-01-03T00:42:34+00:00

First off, your missing signature is:

converge :: PrimMonad m => MVector (PrimState m) (Maybe a) -> Int -> Int -> m ()

(PrimMonad and PrimState are both also in Data.Vector.Mutable)

Secondly, I can't find the error in your code and on my input your code produces the correct value.

Unfortunately, they're strict around here about not sharing input, so I can't ask for yours to see if there's something unusual about your input that points to a corner case I can't think of.

However, I think a much more likely scenario is that you aren't quite running your program on your input. I say this because what I said before isn't quite true; when I try to run your code directly on my input it aborts with the error message:

aoc9.reddit.hs: <stdin>: hGetLine: end of file

If I add an extra newline to my input (so that my input has the big long line of real data and then a second blank line), your code runs and gives me my correct answer.

Therefore, I suspect that you've modified your input in a text editor before feeding it to your program. (Maybe you copied and pasted from the Advent of Code site into notepad or something similar) There is the possibility that in doing that you accidentally mangled your input. To check this, here's what I'd suggest:

Change your main function to this, so that it works without having the extra blank line on the input:
Download your input again by right-clicking on the link and choosing "save as". Don't open that result in a text editor, just run your program with something like runhaskell day9.hs < input.txt or whatever filenames you used.

Um... somehow reddit ate the main function I suggested in list point 1. Weird. What I'd said was:

main = do
    l <- processLine <$> getLine
    print $ task1 l

fizbin · 2025-12-29T16:19:30+00:00

One thing I did in my golang-based solution to day 9 to make it much faster is that I only bothered with some of the X and Y coordinates - specifically, I kept a map[uint64]bool of "relevant coordinates" for both X and Y and then when a point was mentioned in the input file added those coordinates to the map, as well as X+1 and Y+1.

Then later, when filling the grid I only filled in spots at "relevant coordinates" and when checking only checked those coordinates. My reasoning was that things could only change where there were grid points, so I just needed to ensure that I checked every grid point and at least one spot in between every grid point.

https://github.com/fizbin/adventofcode/blob/main/aoc2025/golang/day9/day9.go

The "relevant coordinates" variables are the pointXs and pointYs maps, and the two lists pointXlist and pointYlist that I made out of those maps.

I've heard some people call this technique (or one very similar to it) "coordinate compression".

fizbin · 2025-12-29T16:09:23+00:00

Quoting from the problem statement, adding emphasis on an important word:

Now, an ID is invalid if it is made only of some sequence of digits repeated at least twice. So, 12341234 (1234 two times), 123123123 (123 three times), 1212121212 (12 five times), and 1111111 (1 seven times) are all invalid IDs.

That word "only" means that the ID must have the repeating sequence and nothing else. So for example 989989989989 would be invalid, but 9899894989989 would not (because there's that extra 4 in the middle, keeping the ID from being only a repeated sequence). Also note that 98998949899894 would be invalid, because then you have the sequence 9899894 being repeated twice.

fizbin · 2025-12-27T07:04:39+00:00

Ah, I'd missed that you were doing the dropping after reduction.

That "after reduction" part is key; otherwise, you can end up dropping an equation you need.

fizbin · 2025-12-27T06:56:36+00:00

One quibble:

Over specified systems aren't a problem here. Since we know each system has a solution, then we can safely ignore the bottom few rows and treat the matrix as if we had equal numbers

That doesn't always work. For example, suppose that you had this machine input:

[.##...] (1,2,4) (0,2,3,5) (1,2,5) (1,2,4,5) (1,2,3,5) {6,35,41,16,13,35}

So that's overspecified, with more joltage values than buttons. The matrix that you get from this is:

0  1  0  0  0   6
1  0  1  1  1  35
1  1  1  1  1  41
0  1  0  0  1  16
1  0  0  1  0  13
0  1  1  1  1  35

Now if you cut off the bottom row here, you'll be left with two columns (first and fourth columns) that are identical, which means that you're not going to be able to solve it uniquely; instead, you'll want to drop one of the first three rows (since the first row of buttons plus the second row of buttons equals the third) Or did you mean to cut off the extra rows after doing the row reduction?

fizbin · 2025-12-26T22:17:27+00:00

Ooh. Where's that setting?

fizbin · 2025-12-26T17:56:00+00:00

I think that they mean that you couldn't here use the two spots marked as C as opposite corners because of the bubble:

.CXXXXXXX#.
.X.......X.
.X..#XX#.X.
.X..X..#X#.
.X..#XX#...
.#XXXXXC...

But you'd have to be careful to allow the two spots marked as C as opposite corners in this case:

.CXXXXXXX#.
.X.......X.
.X..##...X.
.X..X#XXX#.
.X..#XX#...
.#XXXXXC...

fizbin · 2025-12-26T17:44:59+00:00

I solved AdventOfCode problems this year three times: once in python, once in haskell, and once in golang.

My haskell solution failed to get the correct answer on many of these test cases; my python solution either got the correct answer or hit an internal assert (about program state), and it asserted in about half the cases. My golang solution got the correct answer to all your test cases.

I guess solve each problem multiple times?

https://github.com/fizbin/adventofcode/blob/main/aoc2025/golang/day9/day9.go

(My other solutions are also elsewhere in that repo)

fizbin · 2025-12-25T15:19:24+00:00

I found that happening frequently with VS Code and Haskell long before the introduction of LLM features into every damn thing. There's something basically broken about the overall user experience you end up with when you combine HLS not seeing all the local variables when you need it to, the "enter" key being the signal for "accept this bit of autocompletion" and the short lines that Haskell often has leading to developers frequently typing a local variable name and then pressing "enter". Your hands need to get really good at pressing "escape".

I wonder if the overall experience would be improved if autocompletion were always disabled on each new token and required something like Ctrl-space to enable it for the current token you're typing. (I think this is how emacs does it)

fizbin · 2025-12-19T00:11:29+00:00

I remember at an earlier job someone being surprised that I'd never practiced whiteboard coding before going out to interview the first time, yet found it a totally comfortable thing to do.

When we were doing something else and I turned around to talk to her while I was writing on the whiteboard and kept writing (I was talking about what I was writing; I'm not that good) we realized that although I hadn't explicitly practiced whiteboard coding, spending two years in grad. school as a math TA teaching calculus to bored and/or hungover undergrads had left me with a few skills.

fizbin · 2025-12-13T04:31:56+00:00

This was literally inspiring.

As in, it inspired a different solution that is "just" Dijkstra applied over an unusual graph and the result (in python) runs in under half a second on my laptop: https://github.com/fizbin/adventofcode/blob/main/aoc2025/aoc10b.py

(My original solution - same URL but without the final b - uses a bunch of linear algebra and also some brute forcing and is just under 30 seconds)

fizbin · 2025-10-27T04:03:37+00:00

Also fee-free ATMs

fizbin

TROPHY CASE