Hacker News Reader

Comment by just2n | Hacker News Reader

So all evidence suggests that the 3rd problem is the hardest, by far, which is likely just some number of non-obvious edge cases.

Curious why the "hard problem" disclaimer is on the 4th?

The 4th also has a 90% solve rate (with 50% more submissions) while the 3rd has 44%.

View on HN

The 4th is definitively the funniest.

In addition to the disclaimer, one thing which worried me was the N <= 1000 in the large problem specification. I got a quite elegant fast solution and a so low bound was really surprising.

My solution for 4 was quite efficient in design (and very simple). I was able to be very inefficient in the rough implementation (being lazy and copying arrays, reading the entire input file at once and breaking it up into lines in memory) and still, using JS, solve the large set in only a few milliseconds.

That should probably be a few orders of magnitude higher to realistically make the time constraint remotely difficult.

This was a fun problem to think about, though. Naomi is such a cheater.

Please don't give potentially useful hints until the end of competition

Yeah, that disclaimer scared me off at first. I solved D last, but in the end I do feel that it's easier than C. I suppose you can solve C-small with a more naive method though.

Agreed. I definitely found D much easier than C. Was able to get C small after a failed attempt, but never stood a chance at getting C large.

To be fair, C large has the biggest score of all subproblems.

The odd thing is, though, I still don't really see how you can solve C-small without solving C-large at the same time (other than actual brute-force). Guess I'll be keeping my eyes peeled for the write-up.

"other than actual brute-force"

spend SO MUCH time on the 3rd. I have too much fatigue to even read the 4th now...

Same thing happened to me, but the fourth was so much more fun to solve than the third.

Reply on news.ycombinator.com