| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | tourist | 3985 |
| 2 | jiangly | 3814 |
| 3 | jqdai0815 | 3682 |
| 4 | Benq | 3529 |
| 5 | orzdevinwang | 3526 |
| 6 | ksun48 | 3517 |
| 7 | Radewoosh | 3410 |
| 8 | hos.lyric | 3399 |
| 9 | ecnerwala | 3392 |
| 9 | Um_nik | 3392 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | cry | 169 |
| 2 | maomao90 | 162 |
| 2 | Um_nik | 162 |
| 4 | atcoder_official | 161 |
| 5 | djm03178 | 158 |
| 6 | -is-this-fft- | 157 |
| 7 | adamant | 155 |
| 8 | awoo | 154 |
| 8 | Dominater069 | 154 |
| 10 | luogu_official | 150 |
Previous part: https://codeforces.net/blog/entry/63606
Apparently, one of problems had incorrect output data. Can someone confirm? On the bright side, no huge technical issues this year afaik.
Unpopular opinion here: Prague isn't a good organizer :O
Also, some disqualification in the top happened :O
The rumour is, the disqualified team sent some rude clarification request in frustration.
I disagree with the disqualification, if this was the case
I was the reason we got disqualified (would be 3rd though, so not much of a difference).
We were having fun sending random stuff in the last problem at the end of the contest. Two seconds before the end we added one fork() call for the lols. We didn't think they would take it so hard since CERC in Prague is one big joke anyway.
But of course you can't argue with their decision.
Entschuldigung, but how did you know that in that moment? Weren't you leading the contest at the end of the 5 hours?
Did that fork crash the system?
Not that we're aware of. Probably it just got "rule violation" verdict.
Then we could say that the joke is on you.
The actual submission https://contest.felk.cvut.cz/19cerc/submits/2014.
What the heck? We got disqualified for a submit that didn't even compile? :|
Yes you did. Your team attempted to send a solution that will violate the rules, and not being able to do that properly doesn't make you less guilty.
Formy popełnienia przestępstwa Art. 13. § 1. Odpowiada za usiłowanie, kto w zamiarze popełnienia czynu zabronionego swoim zachowaniem bezpośrednio zmierza do jego dokonania, które jednak nie następuje.
I guess it from the criminal law? As far as I know in a lot of countries attempts are considered only there.
Don't you find it a bit too harsh?
Even more: don't you find it a bit too silly?
Fucking retarded
Actually we talked to a lawyer about the CERC rules and he agreed that we didn't break them, because they don't mention punishing for the attempts.
No matter how seriously you take ICPC, breaking the rules does not count as criminal act in your home country.
BTW finally our coaches decided not file an official complaint (although we wanted to).
Yes, indeed there was bad test data in one of the problems. As we were explained, the judges' programs all had the same mistake. (I'm not sure if I should spoil the solutions, but it was a textbook error in a textbook algorithm — whenever we teach this algorithm to the students, we always warn them against this very mistake :)). Also, there was no rude clarifications, and no big and juicy secret behind this. But I think this is not anyone's business but the interested team.
Can you please share the exact bug with us? We have no idea what it was
You say it was a textbook error in the algorithm but many teams had solutions that didn't use the same algorithm as the official solution and still had the exact same bug and got AC on the wrong data, including my team. Could you please tell me exactly what that error was, at least in a PM? Another team from my country did use the same algorithm as the official solution and didn't make the mistake, and they don't have an idea what the mistake could be.
In one of the problems, you had to construct an Aho-Corasick finite automaton, with some "accepting" states, i.e. vertices that correspond to completing one of the words. By default, these vertices are only the leaves of the initial tree -- the endpoints of the input words. But sometimes one word is a subword of another one, so you should propagate the accepting states along the "fail" links.
If I understood the explanation correctly, the judges forgot to do that.
Thank you, I think I understand. We did the same thing but in a less efficient manner without the algorithm so we had the same mistake.
ROFL. Yes, that's a textbook mistake that probably everyone who tries to implement that makes at least once.
Was it a problem where it's impossible to write some slow (maybe exponential) brute force? If no then Prague shouldn't organize international contests.
It is possible to write a brute force — just try all possible strings. It's weird that they didn't test the official solution with it.
Well, two things. First: that was obviously a stupid mistake, but I've had my share of stupid mistakes, too, so I'm less inclined for quick judgement. Second: last year, when the Prague system wasn't working at all, I was more fired up and even made a quick inquiry about possible alternative CERC organizers -- not that I could actually do anything about that, but I was actually angry enough to ask around. So...guess how many volunteers turned up :)
You're not supposed to follow that up with a popular opinion.
Wasn't sarcasm obvious enough?
Not outright obvious.
Can someone share final standings?
Here you go: https://icpc.baylor.edu/regionals/finder/central-europe-2019/standings
Edit: The same, but with tasks: https://contest.felk.cvut.cz/19cerc/rank.html
I can surely imagine someone making this bug. Less likely, but I can still imagine three people doing this exact mistake independently (not sure whether these judges discussed this solution between them (bad) or not (good)), but what I am mad about is that they didn't stresstest it against straightforward bruteforce solution what would definitely detect this bug. Having multiple solutions giving the same answer prevents from having stupid implementation bugs, but doesn't really prevent from mistakes in logic of the solution. Stresstesting against themselves two solutions computing the result in two completely different ways gives much better safety than stresstesting two codes implementing the same idea.
To me, stresstesting against a bruteforce is for killing any implementation/logic/anything mistakes that appear with sufficiently small inputs, while having different full solutions is both for those mistakes that only appear with large inputs, having multiple opinions for tuning limits and difficulty, but especially spotting passing solutions that break the problem or have countertests that aren't in the test data. Testing needs some amount of "the setters are dumb and I'm going to prove that".
I can not imagine someone making that bug and sets CERC tbh
Everybody makes mistakes. I do a lot of stupid ones as well even though I have decent achievements in competitive programming. But whatever I do, I take as many precautions as I could if I am aware my mistake could have bad consequences, ensuring myself everything is ok in a way that is not almost bound to guarantee safety. And these precautions here were not taken.
People can make mistakes, but for me that specific bug is not a mistake, but a proof of not understanding AC correctly. I also didn't understand why AC fails when I don't propagate success flags. After understanding why, I realized that actually I didn't know what Aho-Corasick does. I think someone who sets CERC should understand basic algorithms such as Aho-Corasick.
After seeing the standings, I got curious about the difficulty/balance of the problem-set (there are so many teams with 11 — 10 problems solved).
Overall it is sad to see such things happen in a renown contest as CERC. Hope next year it is organized by another university.
It was said that the next year will be organized again by CTU in Prague. The organizers mentioned that the year after that (2021) will be in Ljubljana if I recall correctly.
I think 2020 is Slovenia, and 2021 is Croatia.
Nope. It is indeed 2020 in Prague again, 2021 in Ljubljana.
Anybody know some details about what they said about 2021? I mean that we will have European qualifiers.
Here's a new idea. Organizers should ask random people in discord for help with testing the problems just before the contest.
>implying they don't
>implying it didn't end up with them getting pranked by some Pole and deciding it was a dumb idea
Sounds like a decent story. Wanna share it?
It's a joke using this comment.
I don't know how the thing works, but I think Prague can ask help for Polish coders? They prepare subregional(AMPPZ), so they are trustable and they surely have the experience, isn't it?
I think it's not even Prague in general, but CTU Prague. A technical school, not a CS school. They could already ask MFF UK (the other school), but the main reason is probably that even if the problems are too easy and have mistakes, nobody above them in ICPC will care and the next years will go on as usual.
Btw, does anyone know whether getting disqualified still counts as participating in a regional contest, for the eligibility ladder?
We didn't get the PDF certificate in icpc system :O
I understand that for your it is funny situation, but it shouldn't be. Questions you better be asking: Is this disqualification only for this year or forever? Will other teams from our university be disqualified too?
My guesses would be: you and your teammates are banned forever, university is banned from icpc for 2-3 years.
Interesting, your view of this situation is completely different than mine.
My guesses would be: it doesn't count as a participation, no other team is going to be anyhow involved, the university should file a complaint because of "gross misconduct by contest officials with the intent to harm".
Why wouldn't it count as a participation?
If it was the case, every team performing not so well would have an incentive to add a "fork()" line to their solution in the end of the contest to get disqualified and get one additional attempt.
I assumed that rules explicitly say "calling some OS functions like fork is prohibited". If it is not the case, you shouldn't be disqualified. Otherwise, my first comment stands. Especially if diff with your previous submit is just this fork (which looks like it judging by your comments).
You are basically saying that if you have not qualified for WF you should "slightly break the rules" so that participation doesn't count. This is insane, right?
I'm not saying that it shouldn't count, I simply don't know what are the procedures. And no certificate in the system makes me confused.
Btw, my opinion is that breaking ICPC rules should result in a lifetime ban. However, this is not the case.
The opposite for me: I don't think that breaking ICPC rules should result in a lifetime ban (or, for that matter, ban at all) because some ICPC rules are very stupid (like you can be banned for not attending sponsored events), but most of the stories about bans I heard resulted in some very permanent damage not only for rulebreaking team, but for its university too.
I'm not saying that you did something really bad and should be punished for it. I also don't have anything against Warsaw U. I'm just saying that apparently judges of your regional are angry at you and this can end badly for you and your university.
A similar situation happened in Latin America region (at that time, South America/Brazil site) in 2007 or 2008. A team made a "fork bomb" during the warm-up session. Because of this, the server collapsed, and the team got disqualified.
The same team participated in the next two years, qualifying to the World Finals. Thus, I don't think there is a lifetime ban in such situation (at least in the official ICPC rules).
My guess is that you just get result:YEET and otherwise, everything is the same as if you didn't send a fork and got a non-YEET result.
I hate problems :')