Три последних "общих" контеста: Codeforces Beta Round #58, Codeforces Beta Round #60 и Manthan 2011, выявили ряд моментов в правилах Codeforces-раундов и вообще принципах их подготовки, которые вызвали разгоряченные споры и недовольство некоторых участников. Самый наболевший вопрос - взломы и их оценивание, я затрагивать не буду. Он обсуждается, например, здесь.
Хочу выдвинуть такие предложения.
1. После того, как решение участника прошло претесты, нужно открывать их для этого участника.
Какую роль вообще играют претесты? Согласно правилам, "тот факт, что решение прошло претесты говорит только о том, что оно вполне разумно". "Вполне разумно" - понятие расплывчатое, поэтому подбор претестов очень субъективен. Обобщая опыт участия в контестах, могу сказать только то, что в претестах обычно нет максимальных тестов. А вот крайние случаи могут быть представлены в большей или меньшей степени. Цель претестов - с одной стороны, не пустить взламывать тех, кто не может написать хоть какого-то разумного решения по задаче, с другой стороны, оставить некоторый простор для взломов.
Я считаю, что претесты все-таки должны охватывать значительную часть случаев и не пропускать совсем "паленые" решения, как вышло в этом случае. Но они все равно будут пропускать решения с серьезными багами. Даже если автор не хочет этого намеренно, он может не учесть в претестах какого-то распространенного заблуждения участников. Когда я собиралась готовить свой контест, я спросила у Артема Рахова, сколько всего претестов по задаче. Когда я узнала, что их 5-7 (включая примеры из условия!), это сильно изменило мою тактику на контестах: я стала более тщательно тестировать свои решения. Когда нужно гарантированно сдать задачу с первой попытки (например, на школьных олимпиадах), нужно тестировать хотя бы на 10-15 тестах. Причем скорее на 15, если задача сложнее a+b.
Вот и встает вопрос: если решение прошло претесты, нуждается ли оно в дополнительном тестировании? На какие случаи? Открытие претестов даст участнику возможность решить для себя этот вопрос сразу же по ходу соревнования и не обижаться ни на кого потом за слабые претесты.
2. Выставлять баллы по задачам не обязательно 500-1000-1500-2000-2500, а в соответствии с их реальной сложностью.
Потому что бывает, что задачи A и B, или D и E примерно одинаковые по сложности. Тогда имеет смысл дать за них 750-750 или 2250-2250. Правда, эта идея немного близка к Топкодеру :)
3. При определении сложности задачи учитывать не только сложность алгоритма, но и количество частных случаев в ней.
Эту проблему особенно ярко показал последний контест (Manthan). Задачи D и E (особенно D) опирались на более или менее стандартные алгоритмы и их решение вызвало у многих участников меньше проблем, чем B и C. Тем более, когда идет активный "взломный" процесс, для "взламываемых" и исправляющих свои решения задача все дешевеет и дешевеет. В итоге задачу сдает маленькое количество людей и те, кто сдает, получают совсем небольшие баллы, хотя им пришлось преодолеть значительные трудности. За такие задачи, на мой взгляд, надо давать побольше баллов. Что касается порядка, то ничего страшного, если эти задачи будут A или B - это будет говорить о том, что они не требуют знания чего-то совсем сложного и доступны для начинающих участников. А большая стоимость задачи будет говорить о том, что задача, возможно, содержит подводные камни.
Comments (0)
