Live data from Hacker News

Advent of Code 2023 is nigh

adventofcode.com

71–80 of 319 posts

Re: Advent of Code 2023 is nigh

#71
post #46
post #24

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.

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…

> These edge cases are triggered by fundamentally approaching the problem incorrectly.

That's a bit like you are holding the phone wrong kind of statement. These are just coding exercises, not actual business problems.

Re: Advent of Code 2023 is nigh

#72
post #59
post #46

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.

> Re-using the existing code where possible is the fundamentally right approach to the problem.

Reusing code does not make something "fundamentally right approach". An implementation that actually does what the problem asks is a "fundamentally right approach". If you can reuse existing code in that implementation then that's a bonus.

The problem is very clearly specified, so if you choose to implement something else hoping that it's "close enough" then that's on you...

Re: Advent of Code 2023 is nigh

#73
post #65
post #24

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.

Ok, I'll be that guy... what edge case? My part 2 was 4-line addition to part 1 (see code below, if inappropriate let me know and I'll remove it), and it worked first try. On the other hand, I made a mistake in part one and got it right only on a second attempt... (definition of nums[] omitted) for (j = 1; j

Edge cases such as "1oneight", "3sevenine", "sevenine3" (I made these up to highlight)

Re: Advent of Code 2023 is nigh

#75
post #27

Earlier quoted context omitted.

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.

The potential for overlapping numbers was the thing that tripped up many developers. But a simple “find the first number searching from each end, just like the puzzle instructions asked” implementation just worked. The lesson is to read the puzzle instructions carefully and avoid solving more general problems.

This is what I did and then was confused why everyone else I talked to thought it was a hard problem.

Re: Advent of Code 2023 is nigh

#76
Day one part 2 was relatively rough. Things I learned from it: rust regex crate doesn't support look-ahead, rust onig crate is currently broken in many ways and shouldn't be used (the version in crates.io doesn't compile and the version on GitHub is failing tests and look-ahead isn't working). It was a very frustrating time for me. After 2 hours of troubleshooting the above I used the same approach in python and it took 2 minutes to write. So annoying.

Re: Advent of Code 2023 is nigh

#77
post #74

Genuinely curios why people are so into AoC ... Feels leetcode-y

It's more whimsical. There's a clear end with less pressure and an excited community to discuss with. At least that's what it's like for me (though I do also enjoy leetcode occasionally to be fair)

Re: Advent of Code 2023 is nigh

#78
post #74

Genuinely curios why people are so into AoC ... Feels leetcode-y

At least for me, it's like... infinitely more fun than leetcode. The problems are bite-sized enough that I can usually get something done in less than an hour (although usually there's at least a few in the mix that take a long time to finish). There's a lot of personality in the website and text of the events that add to the fun factor. I like how the problems are broken up into two phases and how the second phase often throws a wrench in my previous solution or forces me to learn some tricky thing to get by.

Re: Advent of Code 2023 is nigh

#79
post #74

Genuinely curios why people are so into AoC ... Feels leetcode-y

When it was done in a private leaderboard in a traditional in-person team working in the same office it was a great watercooler talk topic and code-golf team building topic.

I tried to do it in a remote work team with weaker personal links, and it felt like a chore, so this year I'm not doing it at all. No fun without the in-person code reviews and pair-programming code golfing.

Also many of us tried new languages of paradigms every year.

Re: Advent of Code 2023 is nigh

#80
post #76

Day one part 2 was relatively rough. Things I learned from it: rust regex crate doesn't support look-ahead, rust onig crate is currently broken in many ways and shouldn't be used (the version in crates.io doesn't compile and the version on GitHub is failing tests and look-ahead isn't working). It was a very frustrating time for me. After 2 hours of troubleshooting the above I used the same approach in python and it t…

Rust regex crate author here.

fancy-regex is built on top of the regex crate and supports look-around.

The regex crate doesn't support arbitrary look-around because it isn't known how to implement efficiently.

See: https://swtch.com/~rsc/regexp/regexp1.html

Post reply on HN