4 ms·

These types of puzzles can help educate people as to how things might need to be coded to work in more "real world" situations. At my previous job we used them

These types of puzzles can help educate people as to how things might need to be coded to work in more "real world" situations. At my previous job we used them as the basis for discussion and education amongst the team (hoping to do something similar at current company). For example, taking 2021_day1, the naive solution that reads in all of the values and then iterates through calculating and comparing sums is all well and good, it satisfies the end goal of producing a solution. What if you had 1,000,000,000 values in the input? * A program that reads in and stores all of the values before iterating through them now consumes a non-insignificant amount of memory. What if you had to check the differences between the sums of 100,000 consecutive terms? * A program that calculates and compares the sums (rather than just comparing the two non-common terms) will be doing a lot more unnecessary computation. What if you had to take a seemingly endless input stream and report the running totals at 1,000,000 iteration intervals? * A program that reads all of the input before iterating through it is now unsuitable. ..etc.. Programming is not just about getting the answer, it's knowing where you can do the bare minimum to do that, and knowing under what conditions your bare minimum solution will become impractical and what you would have to do to avoid this. There's nothing stopping people using AoC as a toy to collect all of the stars (surprisingly few people have all 304 stars, it was under 700 last time Eric answered that question in July 2021). But it can also be used for a lot more than that.

piaste 5y ago
I agree with the general principle of naive vs. specialized solution. Using AoC day 1 is probably not a good example of it however, because a lot of modern languages offer streaming iterators, so the naive, declarative solution will still not need to load all the values into memory at once.
- deleted 5y ago
  [deleted]
- lostcolony 5y ago
  I'm not sure what streaming iterators have to do with it; the thing I noted was simply that you only need two values at a time. How you get to them from the input is kinda immaterial; the observation is that you can create a more generalized solution (that will be efficient no matter the size of the input, and no matter the size of the window). In fact, if the windows are only offset by one, you don't even need to do any math. It becomes a trivial two pointer problem. Even with a streaming iterator, you're summing up values (either a lot of unnecessary summations across the entire window, or you're adding/subtracting individual values off, which is one step away from realizing the thing being subtracted, and the thing being added, are the only relevant inputs per iteration). More broadly, it's a neat observation that you can determine the direction of a rolling sum without actually maintaining a sum. And certainly, you can do it without recalculating the sum(s) at every step.
  - mrtranscendence 5y ago
    It may be a neat observation, but you're not pushed in any way to recognize it so I struggle to see how it could be the point of the exercise. It's so dead simple to just code it up naively in thirty seconds that unless you notice the trick right off the bat (or already know it), no one's going to think twice that there might be a more efficient or clever solution.
    - lostcolony 5y ago
      >> so I struggle to see how it could be the point of the exercise I think you make a mistake in assuming "the" point, as in, singular. From Advent of Code's own website - 'People use them as a speed contest, interview prep, company training, university coursework, practice problems, or to challenge each other.' We also have seen people use them as an excuse to start doing something in a new language, and, per this post, to play with Github Copilot and understand what it's doing. So...it's really what you want to make of it. -My- point was simply that if there's an ML model trained with all sorts of approaches devs use to solve sliding window style problems, and it manages to solve the problem but still misses such a generally useful optimization, it does call into question what it was trained on.
  - piaste 5y ago
    > I'm not sure what streaming iterators have to do with it; the thing I noted was simply that you only need two values at a time Yes, iterators have nothing to do with the 'just compare the two changed values' optimization. I brought them up because the parent brought up issues of eager vs lazy loading and reading infinite input streams in chunk.

piaste 5y ago

I agree with the general principle of naive vs. specialized solution. Using AoC day 1 is probably not a good example of it however, because a lot of modern languages offer streaming iterators, so the naive, declarative solution will still not need to load all the values into memory at once.

deleted 5y ago
[deleted]
lostcolony 5y ago
I'm not sure what streaming iterators have to do with it; the thing I noted was simply that you only need two values at a time. How you get to them from the input is kinda immaterial; the observation is that you can create a more generalized solution (that will be efficient no matter the size of the input, and no matter the size of the window). In fact, if the windows are only offset by one, you don't even need to do any math. It becomes a trivial two pointer problem. Even with a streaming iterator, you're summing up values (either a lot of unnecessary summations across the entire window, or you're adding/subtracting individual values off, which is one step away from realizing the thing being subtracted, and the thing being added, are the only relevant inputs per iteration). More broadly, it's a neat observation that you can determine the direction of a rolling sum without actually maintaining a sum. And certainly, you can do it without recalculating the sum(s) at every step.
- mrtranscendence 5y ago
  It may be a neat observation, but you're not pushed in any way to recognize it so I struggle to see how it could be the point of the exercise. It's so dead simple to just code it up naively in thirty seconds that unless you notice the trick right off the bat (or already know it), no one's going to think twice that there might be a more efficient or clever solution.
  - lostcolony 5y ago
    >> so I struggle to see how it could be the point of the exercise I think you make a mistake in assuming "the" point, as in, singular. From Advent of Code's own website - 'People use them as a speed contest, interview prep, company training, university coursework, practice problems, or to challenge each other.' We also have seen people use them as an excuse to start doing something in a new language, and, per this post, to play with Github Copilot and understand what it's doing. So...it's really what you want to make of it. -My- point was simply that if there's an ML model trained with all sorts of approaches devs use to solve sliding window style problems, and it manages to solve the problem but still misses such a generally useful optimization, it does call into question what it was trained on.
- piaste 5y ago
  > I'm not sure what streaming iterators have to do with it; the thing I noted was simply that you only need two values at a time Yes, iterators have nothing to do with the 'just compare the two changed values' optimization. I brought them up because the parent brought up issues of eager vs lazy loading and reading infinite input streams in chunk.