Блог пользователя DonSilvio

Автор DonSilvio, история, 5 месяцев назад, По-английски

Hey, dudes and chicks.

A quick notion: the issue I describe here concerns C++ code, but if the same issue is observed in other languages, be welcome to comment on it.

Recently I participated in a local bootcamp organized by my fellows from the university — it included a contest with the problems designed by the organizers meaning that the statements and the tests were written solely by them and they are only accessible via a private group contest so I can't share a link to them here (overall difficulty was somewhere between Div. 3 and Div. 2 if you wonder). One of the problems turned out to be tricky in an unpleasant way — after squeezing out all the possible time-complexity-related optimizations and still getting a TLE, we got a message from the jury (who must have seen the submission and figured that our approach was correct) that the fix we needed was to add the lines std::cin.tie(0); std::ios_base::sync_with_stdio(0); at the beginning of our code. After we did this, we got our long awaited Accepted verdict.

Before that, I thought that these I/O-related TLEs were a thing of the past — I still remember some contests for schoolkids where I/O was a TL bottleneck, but it was way back in 2016 or so — sometimes you needed to use stdio instead of iostream (printf instead of cout) and if you did not, you risked getting a TL with an otherwise correct solution.

So, I wonder a few things after that. First, is it still preferred to this day to add those I/O speedups? If so, what is the single best way to do this — can you rely on std::cin.tie(0); std::ios_base::sync_with_stdio(0); or is it better to use printf and scanf instead of generally more convenient iostream tools? Secondly, this issue does not seem to depend on the architecture of testing servers as this particular issue happened like 2 months ago, so does it depend on the specific set of tests for the problem and how then to figure out from the problem constraints that the tests may include those with I/O bottlenecks? Finally, does the same issue appear in other languages besides C++ and if it does, what are the general guidelines to avoid these traps?

Appreciate all valuable input, thank you!

Полный текст и комментарии »

  • Проголосовать: нравится
  • +3
  • Проголосовать: не нравится

Автор DonSilvio, история, 2 года назад, По-английски

Hey guys.

I'd like to ask for an opinion of those experienced in solving difficult problems (rating 1900+) — how do you figure out if the solution you came up with will fit into the time limits set by the author of the problem? When I was in school, I was basically taught to assume that 10^6 operations is equal to 1 second of execution time. But later I found out that this is not always the case, particularly with super-fast data structures like bitset. Also, with the evolvement of computers, they now compute faster and some of the problems that earlier had a 2-second time limit, now usually have their TLs set to 1 second. I specifically ask for the opinion of those who have some degree of experience in solving rather difficult problems (for me this difficulty threshold is approximately problem D in Div. 2 rounds (B for Div. 1)) because recently I have been reading some editorials for the problems I haven't managed to solve and to my surprise found out that I discarded the correct approach because I thought it wouldn't fit into the TL and this often has to do with harder problems (almost never with simple ones). For the problems even harder, I sometimes come across their editorials and they frequently go like "you may think that it won't run fast enough but it will, since [blank]" which leaves we curious.

Appreciate all of the useful information you can provide.

Полный текст и комментарии »

  • Проголосовать: нравится
  • +3
  • Проголосовать: не нравится