Три последних "общих" контеста: 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 - это будет говорить о том, что они не требуют знания чего-то совсем сложного и доступны для начинающих участников. А большая стоимость задачи будет говорить о том, что задача, возможно, содержит подводные камни.
1. Претесты, я думаю, должны по возможности тестировать все крайние случаи (чтоб не было обидно сдать с ошибкой - мелким недочетом, даже если его взломают, то будет большая потеря времени), но не тестировать максимальную размерность (и быстрей, и это участник сам должен уметь оценить).
2. Я тоже так считаю, правда немного с другой стороны.
Может нужно чтобы сложные задачи от простых отличались более существенно или даже от суммы простых, ведь за первые две можно получить примерно тоже что и за одну 4, но ее не все могут решить, а первые две почти все если внимательно.
Получается за простые задачи в сумме можно получить больше чем за одну сложную. На топкодере нет такого, и тот кто решит одну за 1000 может расчитывать что его не обойдут те кто ее не может решить. Там очки в геометрич-й прогрессии идут с коэф-м 2, если бы могли так же сделать. Но чем больше задач одновременно, тем сложнее такие задачи составить. Поэтому с 3 задачами намного проще чем с 5.
3. Я вообще не хотел бы видеть задачи легкие по сложности, но большие по коду. Типа на форматирование текста. Интереса кодить такую задачу - никакого по моему. К тому же в обилии кода больше шансов допустить ошибку, и в итоге весь труд - за зря.
И кстати видел как неопытные участники писали решение за куб для N=10^6, после чего их конечно взламывали
Так что за взломы тогда будут - открыл решение, посмотрел ограничения, проверил нормально ли все с типами, глянул сложность и всё? Если логика уже проверена зачем вчитываться в решение, понимать идею.
Я же написал "по возможности".
Глубоко не вдумываясь кажется что это почти не возможно.
Основной "игровой процесс") все-таки решение задач, а взломы - дополнительный. Считаю, приемлемо улучшать процесс решения задач (решение+тестирование), в ущерб взломам.
"Возможно взломы уместно учитывать у тех участников, чьё кол-во решённых задач одинаково. Таким образом повысится ценность сданной задачи. Если же у тебя задач решено больше, то пусть хоть 100 взломов у соперников, ты всё равно будешь выше" - наверно слишком сложная система, к тому же зависимости не только от кол-ва, но и от качества должны быть.
Но сделать задачи взвешенными.
У Google так, по моему неплохо.
А взломы соответственно будут влиять на штрафные очки.
Опишу, зачем мне это вдруг понадобилось. В 79-м раунде по задаче D у меня было два разных недоказанных варианта решения. Я выбрал наудачу один, как потом выяснилось, правильный. Я понадеялся на то, что если выберу неправильный, то он свалится на претестах и я перепишу по-другому. Вот сейчас я ради интереса таки отправил неверное решение - WA, as expected. Но мне всё-таки хотелось бы знать, был ли случай, на котором неверное решение падает, уже в претестах, то есть потерял бы я в случае неверного угадывания целую задачу или нет.
В этой задаче 9 претестов.
Вообще, интересный вопрос, да. Было бы хорошо сделать опцию "запустить решение на претестах" во время дорешивания..