Because I'm a ICPC medalist (not this year though) but not a IOI medalist.
Another evidence is that you only have 5 hours to solve 3 problems in IOI, but you need to solve 10+ problems in ICPC. It's impossible to have all 10+ problems to at IOI level in ICPC.
OK. I think my opinion and definition on "easier" is indeed vague. For "easier", I'm only comparing the thinking difficulty.
Yes, medal is function of ranking but not difficulty.
Nonetheless, I would say that IOI more focus on thinking, which I to some degree is not that good at, while ICPC is more like a mix thinking and implementing. Therefore, my ability to implement stuff can improve my ICPC ranking but not IOI.
As a former ICPC winner, I'd say ICPC is mainly a test of teamwork, given the format of the competition (3 team mates, one computer, scoring that rewards clean solutions submitted quicker, tackled in the optimal order for your three sets of skills, etc).
Sure, you need to be individually good at thinking, etc. But the difference between 1st and places further down the ranking is teamwork.
As a former ICPC participant, albeit not first place (hats off to you), I would generally characterize it as "having a good team," much more so than what's usually considered "teamwork." It is a parallelization/scheduling effort than deep interpersonal collaboration.
(In a certain sense, this is actually the ideal "teamwork" setup in the industry as well, to have a bunch of people who own their part and are trusted by their colleagues take care of it and not step on each other toes than kumbaya let's all get together on the same problem.)
The teams we beat trained as individuals and were selected competitively against each other as their school's "best 3".
We were "just" three friends who had studied together for 4 years, knew each other's strengths and weaknesses intimately, and then for the comp trained intensively on optimising the "parallelization/scheduling" aspects (as you put it) to get the best score in the minimum time. That included both the logistical and mental aspects of recovering from setbacks midway through the 5 hour problem sets.
During the finals, you'd be surprised how many teams' teamwork we saw fall apart when three very smart people under intense time pressure hit unexpectedly failing submissions with the bottleneck of a single computer. ICPC is a genius format.
Are you an ICPC World Finals medalist? Because winning an IOI bronze medal is _way_ easier than even qualifying for the ICPC WF, and less than 10% of the teams at the WF get medals.
I'd go as far as saying that gold at the IOI is probably easier than getting an ICPC medal. (One is individual and the other is in teams, but my point stands).
Not sure by what metric you compare the difficulty, but regardless of the hardness of the problem, IIRC, ICPC requires 100% correctness on test cases to score a problem (even failing one means you don't get the score,) but IOI would admit fractional scores (correct me if I am wrong.)
For fractional scores, it depends on problems. In short, there are two types of problems in IOI. One is traditional problems that requires 100% correctness, and the other is continuous scoring.
The prior can still results in score between 0 and 100, but this is because there are subtasks in the problem. For example, a graph become a tree or even just a linear sequence. Nonetheless, you still need to ensure your algorithm is correct on all testcases in that subtask in order to get the score of that task.
Serious question: Has anyone tested how much money you can actually make doing a month of Amazon Mechanical Turk? (It would make for an interesting YouTube video!) I am curious if it is middle class wages in very poor countries (like Nigeria). Some light Googling tells me that middle class salary in Nigeria is about 6K USD, so about 3 USD/hour (assuming: 50 weeks/year * 40 hours/week = 2000 hours/year). Is this possible with MTurk?
That's ok. AI will kill those off soon enough, and like all winners, rewrite history enough so that that inconvenient theft never happened anyway. It's manifest destiny, or something.
Haven't read the post, but I think there must be something wrong if a type's safety depends on the Drop trait due to the existence of std::mem::forget.
in Vec::drain() by setting the Vec len to 0, std semantically moves all elements from the Vec to the Drain and in in Drain::drop it semantically moves the non drained elements back
i.e. vec::Drain::drop is responsible for not leaking non drained elements, not for safety
and sure not leaking means positioning them so in the vec that the len can be set to a value where all elements from 0..len have not been moved out etc. but that doesn't change that semantically it's responsibility is "not leaking" instead "making sure it's sound".
- initially it was believed you can rely Drop for soundness
- then the rust community realized that this is an oversight -- the so called leakocalipyse
- there also was no easy straight forward way to fix that, in the end it was decided that leaking must be sound and `std::mem::forget` was added
- while there was some initial fallout (e.g. scoped threads and some &mut iterators now leaking collections if leaked) it wasn't to bad as you still can use function scopes to enforce some non leaking (i.e. if you accept a closure you can make sure something runs both before and after it)
- but with async functions a lot of the workarounds don't work anymore as the async function could be leaked mid execution by calling async functions ... so by now some people which rust had taken a different turn back then. But then to be fair this is the kind of "hypothetically wishing" because making leak sound was with the knowledge and constraints available back then very clearly the right choice.
That would make the lifetime last forever, preventing you from ever getting the mutable reference back and causing any safety issues. (Your intuition serves you well, though: graphics APIs designed to commit on a guard type's Drop::drop are prone to panicking, since the GPU driver does not care about Rust lifetimes. To implement that properly, you usually need ersatz typestates.)
The crucial bit for Vec::drain is in these two lines of code, which the article lists but does not discuss:
// set self.vec length's to start, to be safe in case Drain is leaked
self.set_len(start);
You cannot rely on Drop alone for safety, you need a fallback strategy in case of a leak (mem::forget or Rc cycle).
Rust lifetimes only ensure that there is no use after free; there is no guarantee that Drop is called before the end of the lifetime. It's possible to mutably access the original Vec after leaking a Drain.
and fails to properly convey outright stating both in the title and places in the article that drop can be responsible for safety (it can't, in drain it's responsible for not leaking non drained elements, not safety)
Nonetheless, I'm still questioning what's the cost and how long it would take for us to be able to access these models.
Still great work, but it's less useful if the cost is actually higher than hiring someone with the same level.