#adventOfCode day 1 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/01.lua
#adventOfCode day 2,
Implementing a naive algorithm was fine, albeit a little slow on the Pi. Retro platforms will struggle with this one unless I come up with a better solution using numerical methods. Maybe I'll have something for the TI-92+ tomorrow. I'm sure it could handle the example input in Lua, but I want to do better than that.
The Raspberry Pi 2B uses a quad-core Cortex-A7 at 900 MHz. In 2016 this was my all-purpose "desktop" machine used for all tasks. The same Pi is still in service as my web server hosting my website and music. http://edlinfan.duckdns.org/music.html
psf[~] time ./02
Part A, B = 19219508902, 27180728081
real 0m2.188s
user 0m2.180s
sys 0m0.000s
[~] cat /sys/firmware/devicetree/base/model
Raspberry Pi 2 Model B Rev 1.2
[~] head -n 4 /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 57.60
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
Adapted #adventOfCode 2025 day 2 in #LuaLang to use a much more efficient algorithm to fit on #ti92 Plus.
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/02fast.lua
This also found a bug in my port of Lua: math.huge was the wrong value, so a particular loop was never running.
#adventOfCode day 3 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/03.lua
The program runs successfully in TiEmu with the emulation speed multiplier unlocked. It has yet to be seen how long it'll take on the real calc...
#adventOfCode day 4 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/04.lua
Unfortunately, it will not fit in the TI-92's RAM due to how I'm representing the grid. Unless it can be optimized more....
#adventOfCode day 4 rewritten in C
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/04.c
This is a very simpleminded solution with no algorithmic fanciness: it's performing lots of repeated work in Part B.
It was stunning to see a result returned in just 10 seconds on the #ticalc, rather than minutes for previous days. The performance difference between an interpreter and an optimizing compiler is stark! Also, the TI-92 doesn't have a floating-point coprocessor, which makes Lua in particular struggle to run at speed.
#adventOfCode day 5 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/05.lua
The #ticalc doesn't make it through input parsing before exhausting memory. It will be necessary to rewrite in C again.
#adventOfCode day 6 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/06.lua
I'm steadily accumulating a backlog that I need to rewrite into C for the #ticalc. I'm really jonesing to switch back to the DOS-based HP 200LX palmtop... 640K RAM feels mighty spacious in comparison to the calculator. Maybe in my copious spare time I need to track down the memory corruption problem that's stopping the 16-bit MS-DOS Lua from working.
#adventOfCode day 7 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/07.lua
After a couple of days where the TI-92+ has been disagreeable, it was refreshing to get a puzzle where the Lua solution Just Works without memory exhaustion. Though, speedy it ain't. And when I got my camera out to photograph the real calc, I found it had crashed, so you get a boring emulator screenshot of it working instead.... ;)
I'm a little confused why it's this slow on the #ticalc: something about it seems difficult compared to the other working examples. I think it's because my approach generates lots of garbage so Lua's gc is working hard.
#adventOfCode day 8 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/08.lua
Eric is sadistic putting the first big problem on a work night, huh?
I'm lucky that breaking Part A into steps, then stringing together well-intentioned but non-optimal solutions to each step, was good enough to return an answer before the heat death of the universe.
I'm not sure how to make my Part A more efficient - it is O(N2 ) and takes a good 500ms by itself on my PC. It'll be really interesting to learn faster ways from other peoples' solutions.
My Part B is doing obvious repeated work. I left some performance on the table to solve the problem sooner using building blocks I already had from Part A.
Getting this working on a TI-92+ or other retro platform seems like a daunting task!
#adventOfCode day 9 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/09.lua
I'm very pleased with the speed here, although I'm sure looking at other peoples' solutions will deflate some of that pride.
The feasibility of the whole solution relied on a big insight I got while staring at the grid far too long. To avoid spoilers, I won't elaborate here.
My original version took about 4 seconds on PC: I owe some of the later ~20x optimizations to studying a friend's Rust solution after we both got ours working.
#adventOfCode day 11 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/11.lua
EDIT: wow I added 3 lines and now this is one of my fastest programs
Yeah, I don't have day 10 part B results to share yet. However, I took a break from that to do day 11!
It's brute force with a small twist to make it finish before the heat death of the universe. And it's based on intimate knowledge of my input file, so I don't know if it generalizes to others. At least the program itself is short....
Bonus: puzzle input visualized in graphviz!
#adventOfCode day 10 in #LuaLang and #Mathematica
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/10.lua
Ok, finally all caught up and looking forward to some sleep and Day 12!
After a night and day in math land confusing myself with row echelon matrices and intersecting N-spaces, I remembered that I have a Raspberry Pi that for some reason has free preinstalled Mathematica.
So my Lua program code-gens a Mathematica program, which then runs on the Pi to solve Part B!
This generated code is checked in if you want to look at it - it's several thousand lines of simultaneous equations being solved with constraints applied: https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/10.m
Given all that, it's pleasantly fast. Mathematica over VNC on wifi is pretty laggy but the actual execution couldn't have taken more than a second or two!
(Yes, I did attempt to solve the equations on the TI-92+ #ticalc, as it has a very capable computer algebra system, but I couldn't figure out how to apply all the necessary constraints -- maybe later.)
If the system of equations is underdetermined and has M dependent variables remaining when solved, then there are multiple solutions, and the solution space is a M-space:
And for each point in that M-space you can plug back into the equation system to map that point back into the N-space of the original problem
so I had the cracked thought that you use the closed-form solution for "closest point to the origin" (after clipping to the N-space's first orthant to ensure all coordinates are positive), because this generalizes from line to plane to higher dimensions just fine
But distance minimizes the wrong thing... sum-of-squares of the presses of each button... not plain sum of presses. What the problem actually needs is the equivalent https://en.wikipedia.org/wiki/Least_absolute_deviations, and unfortunately, "unlike least squares regression, least absolute deviations regression does not have an analytical solving method".
And then it lists a bunch of iterative solving methods that seem familiar from what people were talking about in the #adventOfCode megathreads. Given that, I feel like I've done my due-diligence and I am happy enough with my existing solution that hands off to Mathematica and uses its solver instead of writing my own.
@psf Yeah, it seemed like a Diophantine equation matrix for integer solutions.
If I understand properly, if we always had the same number of buttons as counters (square system) we'd get the one optimal solution out.
Machines with more buttons than counters can have many solutions, and optimizing gets tedious w/o ILP solver.
More counters than buttons would be zero or one, and we'd assume non-zero since AoC designs inputs
@jeff Thanks for teaching me the word Diophantine equations as that's exactly what these are.
One thing, having nbuttons = ncounters isn't enough, if a button is a combination of other buttons it isn't helpful in nailing down a degree of freedom - like having buttons (1,2), (2,4) isn't more useful than just (1,2), because as equations they're linearly dependent - this is seen in the puzzle input sometimes.
@psf Sure! I actually just wrote down notes on Diophantine equations and Gaussian Elimination so I don't forget it next time. 😀
I mentioned "square" and "full rank" matrices, which disallow the linear combinations you mention.
#adventOfCode day 12 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/12.lua
I wasn't expecting that to work!
And as usual, AoC is a good source of stressing cases to expose crashes/bugs in the #ticalc Lua port :p
Merry Christmas!
This is the first Advent of Code I've ever completed!
Jeff Standen