Why some hacked solutions on yesterday's div3 can still get the Accept now ? Shouldn't those hack test cases be added for all? Otherwise, it is unfair like why the one hacked only to suffer wrong ans or time limit verdict and his rank go down?

Yesterday's D : Hacked 208770029. However, I resubmitted and got AC 208875517

Yesterday's B : Hacked 208823417 That was my 1st solution to the problem. It fails in case n = 1e9 and k = 30 because of taking MOD when doing the binary exponentiation (It was a typo taking the MOD just copying my template but it still wrong)

Another Hacked B 208731078 for K = 63 , it overflows 1LL << K as max for long long is 2^63-1 so adding 1 would overflow

However, why they still pass ? And shouldn't those test cases be added for all contestants ?

UPD : Resolved

An unrated edu round, a +12 hour maintenance then some outages in recent hours and now many submissions are in queue Specifically, a 5 page-inqueue

UPD: It has been all resolved. Now, the queue runs fine and even bots aren't allowed to do submissions. And I guess the human verification imposed will lessen ChatGPT's crazy believers submissions spamming the queue as pointed in this blog It looks that DDOS attack which made the last edu unrated won't happen again (hopefully) by this series of strong enhancements. Thank you MikeMirzayanov and all the codeforces team.

Hello mates. In the recently finished contest, regarding problem B Ela's Fitness and the Luxury Number,I submitted it using cpp 20 64-bit compiler, I got 4 WA verdicts which had cost me a lot of penalty till I solved it(pure coincidence as I tried int128 instead of ll then knew from the compiler error that type-casting is the problem so type-casted the sqrt() argument into long double and AC)

After the contest, I looked over the submissions and saw that many got it AC by cpp 17 compiler so tried my EXACT WA4 code ,but changing the compiler from cpp20 to cpp17. Magically, the same exact code was AC by cpp 17. I concluded the issue is with cpp 20's sqrt() fn, its argument should be type-casted to long double or rather use sqrtl(), but I wanna elaboration on why that happened and how not to fall in that on next contests ?? Here are my submissions: 175013082 The one Finally AC during contest after 10 tries, 175001140 WA pretest 4, 175043791 same WA4 code but AC by cpp17

UPD: It was really a well prepared contest that it rose awareness to avoid using built_in functions like sqrt() or even sqrtl() as they depend on floating pt calculation, I found this blog which is an absolute gem discussing the alternatives to those fns.

I tried implementing sqrt()fn myself using binary search returning an integer as in 175151224 and indeed got AC by cpp20 without any further type-casting avoiding any precision errors. Its complexity is logarithmic and accuracy is guaranteed.