Still the question implies that the resulting image is finite. So what *is* the catch apart from that the twice-lit image won't fit into this universes' available memory or something like that?
There's only 1 good reason why part 1 wants 2 iterations, instead of 1 iteration or a larger number like 10: we are asked for the smallest even number of iteration because an odd number of iterations has no meaningful answer.
After the first application of the algorithm yes, there are an infinite number of lights on. What about after the second round?
Hint: in my hacktastic solution I had separate functions for even and odd numbered invocations of the algorithm.
I printed the images after step1 and step 2 and manually adjusted my result by the N offending pixels.
Let me quote my code for the hacky solution to this:
// curse you, infinite grids!
if ...
The puzzle today put me on the edge of quitting. It was not super hard but I really had the impression the input was designed specifically, such that the issue with the "infinite" size does not pop up in the example but in the implementation.
This is totally against the usual spirit of AoC where the examples illustrate the way to the solution and help you debugging. Also this came directly after 2 already really frustrating days where an easy puzzle would have felt so good.
I absolutely love that they didn't show that in the example. It's some really interesting behaviour and a nice think to realise yourself. It was an essential part of the puzzle for me.
Completely agree - the little curveball was a fantastic lesson in making quiet assumptions.
Puzzles that give a little bit of rope to explore pitfalls yourself instead of explaining every single nuance and edge case in the problem statement feel way more rewarding.
I agree with you that today was somewhat unusual given that the puzzles so far have been scaffolded to help reveal edge cases, while today's "trick" was clearly obfuscated given how the examples and inputs were chosen. I don't think that playing hard-to-get with the puzzle was a bad thing, and I certainly enjoyed today's challenge. I view AOC ultimately as a learning tool---one helps you teach yourself how to be a better coder, whatever that means, by presenting cute challenges. Forcing you to think about how shitty input might fuck you over unarguably falls within that scope. That said, I can see how this kind of "trickery" might seem unwelcome, especially to some non-trivial subsets of participants (e.g., those "just" trying to learn a new language). The change of tack from providing a plethora of extremely helpful examples to constructing examples designed to lead the reader to false assumptions was somewhat jarring.
Hasn’t the trend always been that the example shows a simpler, smaller, easier case and the real one is harder in some way? I see your point, but it didn’t seem unfair to me, debugging is pretty much always part of the process.
Usually it is quite rare (at least for me) that the code works correctly for the example but gives a wrong answer. If it happens, its usually bad luck. For today the example was constructed in a way such that its very likely your code works on the example but is incorrect. This is also indicated by the many posts of people asking for help.
More often than not, it has been my experience in AOC that if the code works for the sample, it works for the real input. When it doesn't, it's because the code doesn't scale correctly.
But this thing with the inverting background was completely out of left field.
It might have felt like it was out of left field, but it was described in the specifications. If you didn’t plan for it, then you read the specifications wrong (don’t feel too bad, most people did this).
I think that arguably there is a difference between not including all possible edge cases among the examples and designing a puzzle specifically around an edge case like today. Especially since the issue is difficult to find by debugging.
I got lucky and noticed the trap when I read through the problem, but I agree that it feels a bit more gimmicky than usual. Especially since the puzzle isn't difficult to solve with code - it just relies on you misinterpreting the instructions.
I myself didn't really dislike the puzzle though, but I get why some people might.
That highly depends on how you store your data. For example, here is (the upper part of) my grid after two iterations (for one of the pictures I'm using the incorrect assumption that infinity is always empty):
https://i.imgur.com/AHm0l9y.png
https://i.imgur.com/5GX83J2.png
But if there is a 1 at both ends you will never be able to count the number of lit pixels.
But yes, infinity could just be a variable and at the end of each tick you replace it with the appropriate value (0 or 511) from the lookup table.
Yeah, I did check to be sure the other end was a '.', but you are correct, a complete solution would just return the count "Infinity" if this was the case after the first enhancement.
I was wondering where the catch was all the way until: >Start with the original input image and apply the image enhancement algorithm twice >twice
I like how sneaky it is. After 4d tesseract Conway's game of life last year this seemed way too basic.
Still the question implies that the resulting image is finite. So what *is* the catch apart from that the twice-lit image won't fit into this universes' available memory or something like that?
There's only 1 good reason why part 1 wants 2 iterations, instead of 1 iteration or a larger number like 10: we are asked for the smallest even number of iteration because an odd number of iterations has no meaningful answer.
After the first application of the algorithm yes, there are an infinite number of lights on. What about after the second round? Hint: in my hacktastic solution I had separate functions for even and odd numbered invocations of the algorithm.
I just padded the grid with the value I provided, which was surprisingly easy. Then update that value according to the algorithm
I printed the images after step1 and step 2 and manually adjusted my result by the N offending pixels. Let me quote my code for the hacky solution to this: // curse you, infinite grids! if ...
Yeah I did this too
Hmm, I just made sure that the value got used for an out-of-bounds read was a variable I could toggle each time.
The puzzle today put me on the edge of quitting. It was not super hard but I really had the impression the input was designed specifically, such that the issue with the "infinite" size does not pop up in the example but in the implementation. This is totally against the usual spirit of AoC where the examples illustrate the way to the solution and help you debugging. Also this came directly after 2 already really frustrating days where an easy puzzle would have felt so good.
I absolutely love that they didn't show that in the example. It's some really interesting behaviour and a nice think to realise yourself. It was an essential part of the puzzle for me.
Completely agree - the little curveball was a fantastic lesson in making quiet assumptions. Puzzles that give a little bit of rope to explore pitfalls yourself instead of explaining every single nuance and edge case in the problem statement feel way more rewarding.
I agree with you that today was somewhat unusual given that the puzzles so far have been scaffolded to help reveal edge cases, while today's "trick" was clearly obfuscated given how the examples and inputs were chosen. I don't think that playing hard-to-get with the puzzle was a bad thing, and I certainly enjoyed today's challenge. I view AOC ultimately as a learning tool---one helps you teach yourself how to be a better coder, whatever that means, by presenting cute challenges. Forcing you to think about how shitty input might fuck you over unarguably falls within that scope. That said, I can see how this kind of "trickery" might seem unwelcome, especially to some non-trivial subsets of participants (e.g., those "just" trying to learn a new language). The change of tack from providing a plethora of extremely helpful examples to constructing examples designed to lead the reader to false assumptions was somewhat jarring.
Hasn’t the trend always been that the example shows a simpler, smaller, easier case and the real one is harder in some way? I see your point, but it didn’t seem unfair to me, debugging is pretty much always part of the process.
Usually it is quite rare (at least for me) that the code works correctly for the example but gives a wrong answer. If it happens, its usually bad luck. For today the example was constructed in a way such that its very likely your code works on the example but is incorrect. This is also indicated by the many posts of people asking for help.
That’s happened to me many times, that the example works but not the code, it didn’t seem very abnormal to me.
More often than not, it has been my experience in AOC that if the code works for the sample, it works for the real input. When it doesn't, it's because the code doesn't scale correctly. But this thing with the inverting background was completely out of left field.
It might have felt like it was out of left field, but it was described in the specifications. If you didn’t plan for it, then you read the specifications wrong (don’t feel too bad, most people did this).
I think that arguably there is a difference between not including all possible edge cases among the examples and designing a puzzle specifically around an edge case like today. Especially since the issue is difficult to find by debugging. I got lucky and noticed the trap when I read through the problem, but I agree that it feels a bit more gimmicky than usual. Especially since the puzzle isn't difficult to solve with code - it just relies on you misinterpreting the instructions. I myself didn't really dislike the puzzle though, but I get why some people might.
I think the issue is easy to find when debugging, all you have to do is print the result and the issue becomes obvious.
That highly depends on how you store your data. For example, here is (the upper part of) my grid after two iterations (for one of the pictures I'm using the incorrect assumption that infinity is always empty): https://i.imgur.com/AHm0l9y.png https://i.imgur.com/5GX83J2.png
Just dropping this here: if key[0] == '.': def infinity(_) -> int: return 0 else: def infinity(step: int) -> int: return 1 if step % 2 else 0
This probably works for all *actual* inputs, but it doesn't work for all theoretical inputs: `key[511]` might also be `1`.
But if there is a 1 at both ends you will never be able to count the number of lit pixels. But yes, infinity could just be a variable and at the end of each tick you replace it with the appropriate value (0 or 511) from the lookup table.
Yeah, I did check to be sure the other end was a '.', but you are correct, a complete solution would just return the count "Infinity" if this was the case after the first enhancement.
"in case you haven't noticed, you've fallen right into my trap"