211–220 of 319 posts
[1] https://kreya.app/blog/solving-advent-of-code-with-kreya/
I like to solve these kinds of problems in Lisp, which means I'm working in a REPL and dividing and conquering the problem to be able to test one piece of the solution at a time.
The result is that my code tends to be mainly independent functions that I finally string together to solve the problem.
I think the edge cases were entirely unclear in day 1, part 2. I had to redo it in a "dumb"/brute-force way to avoid using fancy regex tricks I don't know. It's quite clear the small sample data was chosen intentionally to not cover them.
The problem statement was super clear though. "Find the first occurrence of any one of these strings in a longer string" doesn't require any fancy regex tricks, just a for loop and knowledge about `isPrefixOf` or `startsWith` or whatever the equivalent function is called in your language of choice. "Find the last occurrence of any one of these strings in a longer string" is just the first problem again but with all t…
There's no guarantee the digits are the first or last, so it's more `find` and `rfind`, unless you try every subslice of the line by hand.
Although thinking about it assuming the lines are not too long I guess that also works.
The main difficulty of part 2 is that there are edge cases that are not covered by the examples. I have appended the example list with some edge cases, so use this list instead: two1nine eightwothree abcone2threexyz xtwone3four 4nineeightseven2 zoneight234 7pqrstsixteen eighthree sevenine oneight xtwone3four three7one7 eightwothree oooneeone eight7eight
I don't get the amount of effort people out into the replacement-strategy, I did perfectly fine without it and the code is about as complex as the examples I've seen. https://github.com/codr7/swift-interpreter/blob/main/part10/...
Oh so THAT is what is causing people problems.
Nom already has a parser for numbers. However, I didn't find an elegant way to take at most one digit. In the end I used take_while_m_n, and mapped it with u64::from_str().
Another challenge was absence of something such as find_all, that would repeatedly try to parse beginning from each character and then return all matches. I ended up writing my own combinator.
https://github.com/drola/AdventOfCode2023/blob/main/src/bin/...
Without going into spoilers, its interesting that people jumped to regex to solve this. For me that was a fairly non intuitive when I first saw the problem(both parts). What jumped to me is the problem statement indicated a finite number of states and I crafted a solution based on that information. But its really cool to see how we all jump to different implementations.
It's a tough day 1, I hope it doesn't scare off too many people. Normally day 1 is just some variation of "add numbers in a list", but this year has a mean pt 2 and a few traps for people to fall into. I wonder how long the global leaderboard will stay up before it gets hidden due to people solving with ChatGPT?
Last year they fucked the global leaderboard early, then completely dropped off during week 2, so I can't say I don't welcome it. I didn't find part 2 an issue, but I completely grug-brained it and that was not sensible to the overlap issue.
Part two was exceptionally hard. Many people on reddit reporting they were hit by one edge case that's not covered in the examples. But my implementation passed these edge cases too. I was hit by another edge case. So there are at least two edge-cases (which are in the actual data) that aren't covered in the examples or the description.
Generally, such edge-cases usually make the solution ugly and the process unpleasant. The aim of such puzzles should be a pleasant process culminating with a beautiful solution.
Every year I want to love this. Every year I get four days in before it feels like work. I think I’m just the wrong audience, but I really do want something this well-produced but with perhaps a very shallow diff little curve, bordering on just effortless fun.
I could never do it in one of my work languages.
Earlier quoted context omitted.
Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril. These edge cases are triggered by fundamentally approaching the problem incorrectly. In some ways it's excellent to bring that up early in a way that's relatively easy to debug and diagnose. Like many others I started with the wrong solution, and I was hit by the same problematic cases, but what I found interesting was…
I agree that one should take a step back at that point but how exactly is this the fundamentally wrong approach to the problem? Re-using the existing code where possible is the fundamentally right approach to the problem. It just so happens that in this case, there were edge cases that prevented this, so another approach had to be taken.
I mean, who said you had to use a regex to begin with?