Hacker News Reader

Comment by gray_-_wolf | Hacker News Reader

I am very happy that we get the advent of code again this year, however I have read the FAQ for the first time, and I must admit I am not sure I understand the reasoning behind this:

> If you're posting a code repository somewhere, please don't include parts of Advent of Code like the puzzle text or your inputs.

The text I get, but the inputs? Well, I will comply, since I am getting a very nice thing for (almost) free, so it is polite to respect the wishes here, but since I commit the inputs (you know, since I want to be able to run tests) into the repository, it is bit of a shame the repo must be private.

View on HN

If enough inputs are available online, someone can presumably collect them and clone the entire project without having access to the puzzle input generation code, which is the "secret sauce" of the project.

Are you saying that we all have different inputs? I've never actually checked that, but I don't think it's true. My colleagues have gotten stuck in the same places and have mentioned aspects of puzzles and input characteristics and never spoken past each other. I feel like if we had different inputs we'd have noticed by now.

He puts together multiple inputs for each day, but they do repeat over users. There's a chance you and your colleagues have the same inputs.

He's also described, over the years, his process of making the inputs. Related to your comment, he tries to make sure that there are no features of some inputs that make the problem especially hard or easy compared to the other inputs. Look at some of the math ones, a few tricks work most of the time (but not every time). Let's say after some processing you get three numbers and the solution is their LCM, that will probably be true of every input, not just coincidental, even if it's not an inherent property of the problem itself.

You do get different inputs, but they largely share characteristics so good solutions should always work and naive ones should consistently fail.

There has been the odd puzzle where some inputs have allowed simpler solutions than others, but those have stood out.

I don't know how much they "stand out" because their frequency makes it so that the optimal global leaderboard strat is often to just try something dumb and see if you win input roulette.

if we just look at the last three puzzles: day 23 last year, for example, admitted the greedy solution but only for some inputs. greedy clearly shouldn't work (shuffling the vertices in a file that admits it causes it to fail).

It's only a small selection of inputs.

I have a solve group that calls it "Advent of Input Roulette" because (back when there was a global leaderboard) you can definitely get a better expected score by just assuming your input is weak in structural ways.

It depends on the individual problem, some have a smaller problem space than others so unique inputs would be tricky for everyone.

But there are enough possible inputs that most people shouldn't come across anyone else with exactly the same input.

Part of the reason why AoC is so time consuming for Eric is that not only does he design the puzzles, he also generates the inputs programmatically, which he then feeds through his own solver(s) to ensure correctness. There is a team of beta testers that work for months ahead of the contest to ensure things go smoothly.

(The adventofcode subreddit has a lot more info on this.)

There are several sets of inputs, and it picks one for you.

I use git-crypt to encrypt the inputs in my public repo https://www.agwa.name/projects/git-crypt/ :)

I don't push my solutions publicly, but I made an input downloader so you can input your cookie from your browser and load (and cache) the inputs rather than commit them.

This is cool. Kudos!

This is not surprising at all, to me. Just commit the example input and write your test cases against that. In a nicely structured solution, this works beautifully with example style tests, like python or rust doctests, or even running jsdoc @example stanzas as tests with e.g. the @linus/testy module.

> Just commit the example input

The example input(s) is part of the "text", and so committing it is also not allowed. I guess I could craft my own example inputs and commit those, but that exceed the level of effort I am willing to expend trying to publish repository no one will likely ever read. :)

The inputs are part of the validation that you did the question, so they're kind of a secret.

I make my code public, and keep my inputs in a private submodule.

Reply on news.ycombinator.com