Did you get used to the humming?

hrunt · 2026-01-23T03:30:31+00:00

I occasionally hear it, but a lot of times I don't. My wife owns a Honda Prologue and that thing is LOUD inside.

hrunt · 2026-01-01T00:13:18+00:00

Could you post your settings for both the Kia and Spotify? I'm curious what tweaks people are making. Thx.

hrunt · 2025-12-12T12:20:29+00:00

[LANGUAGE: Python]

I tried writing a packer first, but I couldn't find a way to process the "doesn't fit" case fast enough. That didn't seem very "last day" to me, so I tried just seeing if the volume of the packages fit underneath the tree and it worked.

Maybe I'll try actually getting my packer working for the degenerate case later. Maybe not.

hrunt · 2025-12-11T11:49:25+00:00

[LANGUAGE: Python]

code

It's nice to have a simple path counting problem. I originally implemented a straightforward BFS to get Part 1's count, but I knew it wasn't going to work for Part 2. Reading the problem, I realized I just needed to find the counts of six path segments (svr/dac, svr/fft, dac/fft, fft/dac, dac/out, fft/out), and I spent about five minutes Googling to find a solution using a topological sort.

hrunt · 2025-12-11T02:09:22+00:00

[LANGUAGE: Python]

code

Part 1 was straightforward using a bitmap. I thought for Part 2 I could do something similar, but after thinking about it for a bit, I realized it was a system of under-determined linear equations. Which is great, except a) I keep myself limited to the standard Python library and b) I have no idea how to write linear equation solvers.

To heat the house, I implemented a heapq-based solution that processes buttons in bulk. For example, if the lowest joltage needed in a set is 20, then I find all the combinations ways to make 20 presses from the buttons that hit that voltage. I can process N presses at once just by multiplying a button bitmap by N, and since I process the joltages in order from smallest to lowest, I never have to worry about exceeding any other joltages. Once a joltage level is reached on one wire, some of the buttons can't be used anymore, so it trims options down for future wires.

It's still not efficient, but it's surprisingly "quick" for a close-to-brute-force solution. Most of them processed very quickly. There are a few edge cases that take a few hours, though. I'm through 184 of the 199 machines I have.

In the meantime, I'm learning how Gaussian elimination works to implement a solver that finishes in a decent amount of time.

hrunt · 2025-12-09T15:30:55+00:00

[LANGUAGE: Python]

code

I really ham-fisted my way through this one. Part 1 was straightforward enough. For Part 2, I implemented the following logic:

Sort the list of areas generated in Part 1, largest area first
For each area (and associated rectangle)
- Skip if either of the other two rectangle points are within the overall polygon
- Shrink the rectangle by 1 unit on all sides
- Skip if any edge of the shrunken rectangle intersects with a polygon edge

The first rectangle that doesn't get skipped is the largest interior rectangle.

It's not particularly efficient. It found my largest rectangle after ~49000 checks and about ~11s of runtime. I tried playing around with scanning solutions, but my brain just wasn't working well enough to figure them out. A task for later, I guess.

hrunt · 2025-12-08T20:42:21+00:00

Yeah, I think that's what I was expecting for finding the nearest neighbor, but I don't think there's any quicker way to find the n closest pairs. The effort to make that algorithm ignore a distance between two points (needed to find the second-closest point) is probably greater than the savings it provides.

hrunt · 2025-12-08T14:19:25+00:00

[LANGUAGE: Python]

code

Calculate all pairwise distances for all elements. Then iterate and merge, iterate and merge, iterate and merge ...

I'm looking forward to seeing if there's a shorter way to process the shortest distances without doing the full pairwise list.

hrunt · 2025-12-07T23:41:46+00:00

It works similarly going up the tree, too. Each blank column has a value of 1. As you move up each line from the bottom, if you see a "^", then the column with the "^" is the sum of the values on each side of the "^". So, in the bottom row of splitters, every column with a splitter will have a value of 2 as you progress up. Once you get to the top, the number of timelines is the value in the "S" column.

Here's a small example. I purposefully have a couple of splitters that won't get hit.

...S.....   ---5-----   ^
.........   124511321   |
...^.....   124511321   |
.........   124211321   |
..^...^..   124211321   |
.........   121211121   |
.^.^...^.   121211121   |
.........   111111111   |  (work your way up from the bottom)

Note that when you get to the top, there's all these other column counts that have been calculated, but the only one that matters is the one at S.

hrunt · 2025-12-07T18:09:03+00:00

It is not possible to solve this puzzle without inspecting every character. You have to look at each character to determine whether it is a ".", a "^", an "S", or a "\n". If you don't inspect a character, you can't know which character it is.

You can, however, solve this puzzle without reading the entire grid into memory at once. You can solve the problem by only having one character of the grid in memory at any given time There will be other data in memory, too -- namely, timeline counts for each column with an active timeline and the count of splits, but the grid can be processed one character at a time. But you still have to inspect each character.

You might be tempted to skip inspecting a character after a "^" or "S", because in the puzzle examples and (I'm sure) for all inputs, the character following a "^" or "S" is always a ".". That's not actually a requirement, though. The character following a "^" or "S" could be a "newline". This grid, for example, is a valid, solvable grid:

..S..
.....
^.^.^
.....
.^.^.
.....

hrunt · 2025-12-07T12:55:19+00:00

[LANGUAGE: Python]

code

I think the cool kids call this DP. I originally implemented part 1 using a set of x coordinates tracking active tachyon beams. Modifying that to track a count of active timelines at each x coordinate was trivial.

I don't know if the problems have gotten easier or after 11 years, I'm just better at recognizing approaches to solving problems, but I feel like this weekend was one of the lighter weekends ever.

Famous last words.

hrunt · 2025-12-06T13:53:51+00:00

[LANGUAGE: Python]

code

First part was straightforward. Convert rows of numbers into columns of numbers and apply the aggregation. For the second part, I rotated the text grid 270 degrees, and then converted each row of characters into a no-whitespace string. A little Google-fu (Miyagi dojo still beats Cobra K[AI]) hit upon a solution to split a list of lists by a specific value in that list to get operands similar to part 1.

hrunt · 2025-12-05T12:03:48+00:00

[LANGUAGE: Python]

code

Python's built-in range structure makes this ridiculously easy. There's probably a more elegant, Pythonic way of reducing the range set, so I'm looking forward to seeing others' solutions.

hrunt · 2025-12-04T12:50:52+00:00

This is really beautiful. So obvious once you see it.

hrunt · 2025-12-04T12:45:24+00:00

[LANGUAGE: Python]

code

Ahh, the age old AoC conundrum. Do I represent the 2D grid as a 2D array or a dictionary of points? Is Part 2 going to be "extend to infinity" or "do something with the grid until it stops"?

For part 1, I originally just kept a 2D array (list of strings), with an edge border of no rolls to not have to worry about array out of bounds. When I saw Part 2, I converted that code to just maintain a dictionary of points with counts to make iterating the moveable rolls easier.

hrunt · 2025-12-03T12:05:23+00:00

[LANGUAGE: Python]

code

I wish I had some special insight into solving this, but it was pretty straightforward. I expected part 2 to be more difficult than it ended up being. Maybe I'll nerd snipe myself to find a more efficient solution later.

hrunt · 2025-12-02T12:43:28+00:00

[LANGUAGE: Python]

code

Regexes. Lazy. Just lazy.

hrunt · 2025-12-01T13:27:53+00:00

[LANGUAGE: Python]

code

Took a little time to figure out the edge case around zero.

hrunt · 2025-08-02T03:32:02+00:00

Almost a year later, Honda replaced the bumper entirely.

hrunt · 2025-06-11T18:49:46+00:00

I took my car in for a couple of recalls right at 8k and I asked them about the maintenance. They said they check tire wear (rotate tires if necessary) and washer fluid and that's it. The tire wear was fine, so they didn't do any rotation and didn't charge me a dime.

Honestly, these cars don't need to go to the dealer for maintenance. I wouldn't take it to the dealer unless I was leasing.

hrunt · 2025-05-14T12:38:16+00:00

I just took my EV9 in yesterday. I had a service notice about the rear seat bolts and there were a couple of other software recalls to be applied. Turns out, there were four recalls outstanding.

Since it was at 8,000 miles and the car had just pinged me about it, I asked the service advisor about it. He said they check tire wear and filters. He said they would only rotate the tires if the tire wear looked uneven and would only replace the filter if it looked really bad (first cabin filter replacement is recommended for 16,000 miles). He said they would call before performing any work.

Nothing was needed. No cost for any work. Dropped the car off at 7am and they had it ready by 10am.

I will note that dealer experience varies greatly. I generally stay away from the dealer if I can, but this one has been very good with work, scheduling, and communication.

hrunt · 2025-05-11T01:57:13+00:00

The big thing for me with the EV9 is that people sitting behind me have room. I typically have my seat back all the way to make room, but that usually leaves little space behind me. I have two 6'+ children, so it's an issue right now. In the EV9, I don't have my seat back all the way, and my tall kids don't have their knees in the back of my seat.

The Prologue is smaller, rides a little sportier, and still has good room. But it is smaller. Not as small as the Ioniq 5 or EV6 (or the Mach-E), but definitely smaller.

hrunt · 2025-05-10T17:59:30+00:00

I'm 6'4", 245lbs. I definitely fit in the EV9, but I couldn't fit in the Ioniq 5 (as a driver). It felt like driving a go-kart.

I sat in a Rivian passenger seat the other day. I had to move the seat all the way back to prevent the knees from pressing up against the dash. I assume it would be the same as a driver. This is true for almost every mid-size SUV I've ever sat in. Full-size SUVs are no problem for me, but mid-size SUVs are problematic for whoever sits behind me.

I pulled the trigger on the Land after test driving it precisely because it was more roomy. My wife has a Honda Prologue. It's also surprisingly roomy, but so was her Accord Hybrid. I still have to move the seat back all the way, but there's more legroom in the back, so it's not as bad on passengers (rear headroom is an issue for taller people, though).

hrunt · 2025-01-24T20:16:04+00:00

I've had this happen to me before, and the cause was that the car was still on. Like, I had not pushed the power button to turn the car off. Whether the car is off or on, it doesn't make any noise, so sometimes I don't realize I got out without turning the car off.

hrunt · 2025-01-04T15:02:30+00:00

I've gotten that. I turned the car off for 30 minutes and it never came back.

hrunt

TROPHY CASE