From the past rounds I've looked at, it's usually out of 100, and for round 1 you usually need to have gotten AC on the first two problems to advance.

It looks like you've been able to submit since. That may be some transient infrastructure issue.

Only for round 2 onwards.

I think the easiest way to find out is to just look at the input, you can even instrument your code to measure coverage.

The scoreboard is realtime, though it doesn't show any summary stats like how many people have submitted for a given problem. You'd have to page through to get a rough estimate.

The input size was quite small compared to a normal Codeforces problem, it's possible you ran out of stack space or something.

One of the reasons we added zip files this year was to avoid having you handle that relatively unpleasant format. Unfortunately the zip file for C has an issue that we're investigating. Once that's resolved, I do think the zip files are a much cleaner way of handling large input than making contestants generate the input on their own.

Input generation is terrible and it doesn't allow the test data to be as flexible as possible. I couldn't submit C too and I can guarantee with you that the input size is perfectly fine.

Hey, my C also Segfaulted on the real input, and I couldn't fix it in the 6 minutes. It turned out to be a stack usage problem, because when I set my stack to 200 MB with compiler flags, it ran fine.

Lol, you are probably the first person on planet Earth to advocate for compressed input format if there is an option to do it normally

vkgainz I have faced the same problem earlier. I solved it by increasing the stack space limit. If you are on ubuntu, the command to increase stack size is ulimit -s desired_space(in KB). For example, if I want to set the stack space to 1GB, I would run ulimit -s 1048576 in the terminal.

I don't know if you solved your problem since, but my solution was actually crashing on a (slightly overloaded) DFS for the C, because of the stack size. When I switched to a native Linux (as opposed to WSL) and increased the stack size (using ulimit -s unlimited in the shell), there was no problem anymore.

same even my pc crashed for A1 and B both and now i am out even after solving 2 questions

A common issue was people writing O(N^2) solutions to problem A when O(N) solutions are necessary. You won't be able to run an O(N^2) solution in 6 minutes when N = 800,000.

where to add , i have submitted the wrong output but then also Edit- i added inside the vs code terminal where flags like c++ , a.out and more like that are given its only taking time and no output is coming and on sublime its giving wrong

It is really annoying when purples can't set stack size

For the sake of completeness I'd like to note that GCC can kind-of auto-grow the stack if you specify the -fsplit-stack compiler flag, — see https://gcc.gnu.org/wiki/SplitStacks There's some overhead involved, of course.

Same bruhhhhhh but for A1 , from now on i will declare all arrays and matrices in global scope :(

Does declaring all variables globally solves the problem of stack size?

I had to do g++ -Wl,-stack_size -Wl,160000000 with Homebrew GCC on MacOS.

I wish I knew this before, could not submit C in time due to this.

https://mirror.codeforces.com/blog/entry/94726?#comment-838535 try this

LoneFox Sir, I ran code on Dev-C++ and A1 submitted successfully. But for A2 my code was correct but couldn't figure out how to set stack size in Dev-C++.

Please give a chance to all those who did the 1st question, if you want I can send my source code for A2 to check my submission.

The problems are much easier than I expected, feels like it's another Qualification round after all.

cutoff was too low, it should have been at least A1+A2+B1 imo

Maybe this is the reason: https://mirror.codeforces.com/blog/entry/94802

You can set stack in WSL2 (you cannot in WSL1). Just do ulimit -s unlimited and it's gonna work. That's what I did.

Also I feel like people should be prepared for this. It happens every single year. Especially if you hit it before.

I hit it on a Round 3 and failed the B problem, and I knew it was only my fault I didn't prepare to have stack extra command up. So people should complain even less that it's happening on a round that only qualification matters.

Putting it into FAQ would be surely useful. But the whole situation is really weird. People, who are supposed to be competent programers, happen to be unable to create programs that run correctly on their own computers! A wheelbarrow without a wheel.

You don't need a stack to solve it.

Just in case you don't want to deal with platform specific issues, there is a way to use allocate a custom stack on the heap, and use that for the duration of the program. I found this code in some comment quite a while back, and it works on Linux at least (it would be great if someone could confirm if it works on other platforms, although I would presume it to work on Windows/MacOS as well).

#include <bits/stdc++.h>
using namespace std;
void main_() {
    int n;
    cin >> n;
    cout << n << '\n';
}
static void run_with_stack_size(void (*func)(void), size_t stsize) {
    char *stack, *send;
    stack = (char *)malloc(stsize);
    send = stack + stsize - 16;
    send = (char *)((uintptr_t)send / 16 * 16);
    asm volatile(
        "mov %%rsp, (%0)\n"
        "mov %0, %%rsp\n"
        :
        : "r"(send));
    func();
    asm volatile("mov (%0), %%rsp\n" : : "r"(send));
    free(stack);
}
int main() {
    run_with_stack_size(main_, 1024 * 1024 * 1024);
    return 0;
}

...Or you could generate random maxtests to check wheither your solution processes them reasonably fast and then notice that the answer overflows. That was precisely my case with that problem.

And, by the way, "always do not forget to test wheither maxtest processing fits in time limit" was my takeaway from another failed round (it's highly possible that was a FHC round).

There are a couple of ways you can avoid falling into this pit. If you look at lots of solutions from top competitors you'll see that they use a structure called 'Mint', on 'Mod_int', or something similar. The functions +, — etc are then re-defined according to modular definitions. This means you can't 'forget' to take the mod, as it happens automatically.

My solution contains a similar idea, where I define operations add_, sub_, etc. I've pasted it here for you. I think the first way is probably neater but I developed this myself before I saw that and it works for me.