I slept about 5 hours the night before due to the translation session, then spent 5 hours manually verifying each submit on Scissors and Tape to make sure our checker is correct. I had a cold and a fever and wanted to go to sleep soon. I even considered not competing at all. So I didn't really think about strategy and just solved things.

When I found out I am third after ABC, I concluded I have a decent chance of advancing and solved D properly with brute force solutions and stresstesting. This almost costed me advancing, as I mistakenly used the $$$O(n^3)$$$ brute force to solve the test input. After three minutes I noticed it and just changed brute() to smart() and called it a day.

B was trivial, and A / C is really hard to write any brute forces. How did you implement the stress tests?

I wrote the brute force for D and tested against a single $$$n = 1000$$$ test case, which took almost no time. I don't claim that implementing $$$O(n^3)$$$ is trivial, but you can just directly translate that code into $$$O(n\log n)$$$. For problems like D, it's helpful to implement brute force even if you have complete feedback.

And not optimizing speed sounds really bold to me. Respected coders like you can only do that. I believe the majority of participants go to FHC/GCJ/etc because they just solved problems fast. Even if you want to only focus on problem points, you should solve problems fast enough, because contest time is only 3 hours. Isn't it?

After solving A and B quickly, I thought that I'm able to solve everything and that likely it will be required to advance. I'm replying to ko_osaga below.

There are a lot of factors you need to consider in order to smartly choose whether and when to spend a minute or five minutes checking your solution.

It's easy to check N=1, sometimes also easy to check running time for max N. You can use a lot of asserts that might help you when running your solution on a downloaded input file. Spending an extra minute in A will increase your total penalty time more than doing the same for C or D so you shouldn't test A (or B) too much.

Use the time after submitting. Check if your solution doesn't print any stupid values (negative or infinity), run with sanitizers to check for overflows or RTE. Read the code one more time. Some of my friends don't open the next problem before the timer runs out. This is too extreme IMO but still not that stupid for someone on high-red level.

For A (light show / lasers) in this contest, even if it was trivial to implement some exponential brute force, I wouldn't do it. One reason is explained above, the other is that the problem looked very hard otherwise (if my simple dp idea didn't work) so I wouldn't solve it anyway — so why waste time for testing?

It made sense to test B but also sample test looked strong enough. I just made sure that my sample output is correct as there were multiple valid solutions you can print.

In C, my friends later told me a nice idea. If your solution computes some probability for different possible events, their sum should be equal to $$$1$$$ — make an assert for that. I didn't do that but before starting timer I noticed that the sample test doesn't have $$$A = B$$$ cases so I ran my solution with line $$$A = B = 1$$$ and $$$A = B = n$$$, both should give my all answers $$$0$$$.

After coming up with an idea for D, I wasn't sure about the correctness so I started with a brute force. It didn't work, I drew and analyzed one of test cases, came up with a fix, got it working for sample tests. Then implemented the fast version, spent a few minutes implementing random generator ($$$par[i] = rand(1, i - 1)$$$ and permutate vertices), tested the two solutions on random tests. Actually, with nice time on ABC it was optimal for me to test my solution for half an hour more before submitting. So I should have implemented something exponential because ofc. my testing didn't check if my idea is correct at all. And I should have created various max tests to see if my solution isn't quadratic. But well, I was busy that day and wanted to get back to something else.

All that being said, I used to use a completely different strategy and I still think it makes sense for people that are not likely to advance. Just take a huge risk. Assume that your idea is correct, don't implement any brute force, submit immediately after passing samples. Actually, I still use some of this in onsite finals to fight for the first place. And I will use it in TCO R4 because I'm below top8 level.

One final thought: IMO, people suck in qualification rounds compared to regular CF/ATC/TC rounds. Maybe a single best piece of advice is: just solve problems and don't think about the competition too much.

That's a typical practice on such contests. After your solution is finished and works on samples, you implement some easy-to-code but slow approach and test it against the main solution on random tests. And only then you actually submit your solution.

The downside is time lost on this, that's why on contests like ICPC it is rare to do stress-tests before submitting. But on FBHC there is only one attempt, and the cost of mistake is high, so many people actually do it. Of course sometimes there are rounds like the one in question, where time penalty turns out more important than usual, and people without stress-tests (and without mistakes) have advantage.

I have quite easy log(n) online too. I don't compress paths though. Just don't go further up once you have someone with at least two active descendants.

That sounds like the basic idea of my solution, but I was using heavy-light decomposition and for each path storing a std::set of the nodes in each state so that I could find the nodes that needed to change states. But then I also needed some Fenwick trees for counting, and a bunch of extra state to ensure I didn't count a single subtree with two bribed nodes as being 2+ subtrees, and it was getting very messy.

What I did in the end is precompute the time at which each node would enter the state of "2+ subtrees with bribed nodes or bribed itself". That's pretty easy to do (just compute minimum ID in each subtree, and then look for the second-smallest child subtree of each node).

That's true, I actually checked this during my 6 minutes and noticed that my solution does at most one useful iteration of the while (ok) loop on all 250 test cases.

Assume that there exists $$$i$$$ such that $$$O_i = \text{'L'}$$$ and $$$V_i < 10^{18}$$$. Then for each prime dividing $$$V_i$$$ we can find its power naively and for each prime that doesn't divide $$$V_i$$$ its power is the same as in $$$R_i$$$ so we divide $$$R_i$$$ by all divisors of $$$V_i$$$ and multiply by the result.

If for all $$$i$$$ with $$$O_i = \text{'L'}$$$ we have $$$V_i \geq 10^{18}$$$, then for all such $$$i$$$ find prime divisors of $$$R_i/V_i$$$. Let $$$P$$$ be the set of all these primes. Then for each $$$p \in P$$$ we know the power of $$$p$$$. For all other $$$p$$$ we have some unknown upper bound on its power. Let's forget about it, calculate lcm of our current answer with all $$$R_i$$$ with $$$O_i = \text{'G'}$$$ and check that this number satisfies all conditions in the end.

Regarding 250 tests, most of them are small, there even were some complaints regarding that.

Well, if you are dealing with sane problemsetters then that's good assumption, but not every problemsetter is like this. I actually had a pleasure of participating in a lot of contests organized by Jagiellonian University that has many solid people producing actually decent task, but they always do some shit like "t<=2e9" or "t<=1e6, n<=1e6 (and n numbers in the input per testcase) and they never gave any constraints on sum or whatever and we need to rely on an implicit never stated assumption that if our program is fast enough to pass one maxtest in a reasonable time then it is fast enough to get AC. Even after many complaints from many people they refused to change it ever and they were getting away with some really stupid arguments behind it. And it was quite serious issue since they organized CERC for 3 years (contest qualifying to ACM ICPC finals). And FBHC is bringing to me these haunting flashbacks again.

Of course you are right that relying on some unwritten assumption is a risk, but I don't want to be in a situation where some people took that low risk and got away with some slow solution whereas I don't know whether I should be submitting my solution cause I don't want to take that risk. This is programming contest where your result should depend on your skill, not some casino where your result depends on risk you decided to take and your luck. Moreover in discussion about recent FBHC rounds you can read some comments like "but in FBHC number of maxtests is always small", or "oh, this solution to that new hypothetical task with enlarged constraints would actually be fast enough since there were just a few maxtests". It's not just me and people kinda take it for granted, but I don't want to have that uncertainty.