Tips for heuristic/bot programming contests

Psyho @FakePsyho

#22: [H] Use a good local tester. The absolute minimum are two functionalities: - multithreading (ability to run multiple tests on separate threads) - relative scoring (which is a standard on topcoder). If you don't have your own, use mine: github.com/FakePsyho/mmte…

Psyho @FakePsyho

#23: Testing speed is often a limiting factor. When your solution is compact and easy to extend, you can add/remove features in matter of seconds. That means at some point in the contest, testing different versions of your solutions is going to be main bottleneck.

Psyho @FakePsyho

#24: Use external VMs for quick testing. If you don't have a powerful machine, you can use AWS/GCP/Azure for quick testing. It takes around 1-2h to learn if you have linux knowledge. With spots, for 5$ you can get an equivalent of your laptop running for a week.

Psyho @FakePsyho

#25: Run your tests as often as you can. You have a built-in end to end testing coming with your contest. Testing is your magical command that detects that you've made a mistake somewhere. It also gives you feedback on every possible incremental change you're able to add.

Psyho @FakePsyho

Let's go back to general tips: #26: Version control is bad. You may be very experienced with git and you may feel that it doesn't slow you down. And that might be true. That being said, if you feel it's useful for you then you're bad at prototyping. Fix your prototyping skills.

Psyho @FakePsyho

#27: Version control is bad. Except when running tests. When you run tests, it's useful to save your current source files. This mostly functions as a sanity-check when you get unexpected results. Just a make short .sh/.bat script that saves source files when testing.

Psyho @FakePsyho

#28: If you're ever wondering if it's worth optimizing your code, you run your solution while extending the time limit. This is a simple trick that gets used very often. Don't optimize your code if potential gains are very low.

Psyho @FakePsyho

#29: Language choice: C++ is the lone king*. If you know what you're doing you can squeeze much more out of C++ than any other language, while macros can fix many of C++'s problems. *I don't have experience with rust + very complex topic, so don't take this as golden standard

Psyho @FakePsyho

I need a break. I'll be back later though. I won't lie, I wasn't expecting that many likes. I'm never getting to 400 tips because at that point I won't even remember what I wrote earlier 😅 In the meantime, please check out current contest on CG: codingame.com/contests/fall-…

Psyho @FakePsyho

#30: You should prioritize removing bugs over anything else. When you have bugs, your solution doesn't work the way you believe it does. This means that every time your tests run, you're getting incorrect results. Your intuition for the problem won't properly develop.

Psyho @FakePsyho

Very Important One: #31: Every time you suddenly get results that do not align with your intuition you should investigate. Either you have a bug (see above) or your intuition is off. For latter, you should treat this as a learning experience and figure out why you were wrong.

Psyho @FakePsyho

#32: Try to keep your solution small. More code means: - more bugs - remembering full solution is much more mentally demanding - (usually) more dependencies -> costly refactoring Most of the winning solutions are around 400-1000 lines of code.

Psyho @FakePsyho

#33: Read editorials after every contest you participate in. In all of the platforms I have mentioned, (nearly) all of the top competitors describe their solution after the contest is finished. It's an incredible waste of opportunity to compete and then not read what others did.

koyumeishi @koyumeishi_

マラソン界の王者Psyho先生が極意をまとめてくれてる * プロトタイピングの速さ大切 * 高度数学？イラネ(ベイズを除く * 局所探索は焼き鈍し以外忘れてヨシ * テスト環境大事 * VCSそんないらん * 一つの問題を極めるのがいい経験 * バグ取り大切 * 直感に反するとこにはバグか学びがある などなど twitter.com/FakePsyho/stat…

Psyho @FakePsyho

Let's make a silly experiment. For every like this post receives in the next 24 hours, I will post one tip for heuristic/bot programming contests. I will start posting these as a thread in ~1h from now. I could talk about those things for days, so bring it on!

2022-12-21 23:28:37

Psyho @FakePsyho

Now, let's talk about why some people are consistently good in those contests while others consistently struggle: #34: The obvious one first. It takes time to develop a good solution. There's no magic trick or workaround. Over time, you'll get faster though.

Psyho @FakePsyho

#35: Execution > Idea. You may wonder, why you often find many different approaches at the top, but all of them achieve similar scores. Executing your idea well is generally way more important than the having the perfect idea.

Psyho @FakePsyho

#36: Reread the problem statement until you remember every small detail of it. Read the tester code as well. There are often small details that you may have missed on your first reading. Read the supplied code as well, especially if it involves non-trivial logic.

Psyho @FakePsyho

#37: Find what motivates you. The biggest driving factor for most competitors is the joy of self-improvement. H&B contests are mostly a solitary game where future you tries to be better than past you. Treat others competitors as a benchmark and not as your goal.

Psyho @FakePsyho

#38: Don't waste your time on solutions that can't get you far. If you know that the current solution is not able to achieve good results, there's no point in squeezing maximum value out of it. The easiest way to end up at the top of the leaderboard is to aim high and fail.

Psyho @FakePsyho

#39: Tools increase your productivity. By a lot. For H it's mainly a local tester. For B it's a local league system (although it's less reliable). My estimate is that after polishing my local tester (linked before) I'm spending around 30-40% less time on contests.

Psyho @FakePsyho

#40: Good competitors never run out of ideas. You can get more inspiration by running tests, looking at the visualizer (H) / games (B). You get ideas by working on your solution. At the start, even the best people have no clue what's the best solution is going to be.

Psyho @FakePsyho

Switching up again. Since a lot of people from CodeForces joined in (thanks Mike😁), let's talk about differences between your classic competitive programming (CP) and H/B contests. For the record, while I no longer do classic CP, I was ranked 4th at topcoder at some point.

Psyho @FakePsyho

#41: CP and H/B contests require completely different skills. CP is a sprint, requires insane concentration and a large knowledge base H/B are marathons, it's mostly long-term planning and creative thinking/problem solving

Psyho @FakePsyho

#42: In CP, your "opponent" is the problem setter. In H/B (but mostly H) your opponent is the past you. In H/B you're never done with the problem and solving is an ongoing process. You have to fit your life between the coding sessions. It's very hard to switch between problems.

Psyho @FakePsyho

#43: In CP you care about the worse case. In H/B you care about the average case. This opens a complete new class of techniques: - randomized algorithms - different versions for quickly handling special cases - pruning (early exits)