Выскажусь, как один из соавторов контеста и главный ответственный за качество.
Во-первых прошу прощения у всех участников за сложившуюся ситуацию. Я прекрасно отдаю себе отчёт в том, что независимо от причин возникновения проблем, их всегда можно избежать, если контролировать каждый шаг и делать всё заранее.
Но в начале о хорошем. На Олимпиаде ЮФУ оба турнира прошли практически идеально. На личном турнире мы сделали 2 клара до начала контеста, вызванные найденными уже после распечатки условий неточностями. На командном две команды не смогли сдать решение O(MK) на задачу F по причине непопадания в кэш из-за неправильного порядка размерностей (от меньшей к большей) — когда мы делали эту задачу, мы и предположить не могли, что такая с виду мелочь может столь сильно влиять на результат (замедление в 8-10 раз). Жюри действовало стандартно — был взят большой запас от эталонного решения (700 мс. на Java, 2500 мс. на C++) и запас от неправильного (~6 сек. O(NM)) — итог TL = 4 секунды. Так или иначе, все участники были в равных условиях. Я считаю, что ситуация с задачей F — это, пусть и неприятный, но всё-таки опыт: мы как авторы просто будем остерегаться задач с такими размерностями, а участники теперь знают об этом подводном камне и в будущем не допустят такой ошибки. Добавлю, что ни одного решения за O(NM) на онсайте сдано не было, несмотря на множество попыток. Никаких других проблем с условиями, тестами или решениями на онсайте не было.
Теперь о грустном, а именно о Гран-При Приазовья.
Во-первых, уверяю Вас, что авторы расстроены сложившейся ситуацией ещё больше участников, потому что для участников это 5 часов, а для нас это месяц подготовки, две недели бессонных ночей, прогулов на работе, заведомо отрицательный профит и удар по здоровью и нервам. Одного из авторов в решающие дни перед контестом вообще срубило с температурой 39.5, что тоже в итоге сказалось на результате. Теперь по конкретным проблемам:
1) Задача E "Шахматы вслепую" изначально планировалась автором как несложная, остальные члены жюри в это поверили (судя по числу AC до и после реджаджа большинству участников тоже так показалось) и поэтому работа над ней велась не в первую очередь. Когда дело дошло до кросс-решений и проверки полноты тестового набора, ошибка со слонами всплыла. По-началу мы расстроились и планировали пойти на изменение условия, но когда автору удалось её решить — оказалось, что задача намного интереснее, чем была изначально. Корректная версия тестов была загружена 24-го числа в районе 4-х утра :) Соответствующий комментарий об изменении решения и тестов в полигоне был сделан и ушёл всем в рассылку, правда без капса, восклицательных знаков и тому подобного. Координатор Кубка выгрузил пакет тестов ночью 24-го числа до внесенных изменений, впоследствии не обратив внимание на пришедшие оповещения о нескольких коммитах.
2) Задача F "Генеральские часы" — в условиях Открытого кубка был указан TL 15 секунд. Когда мы это увидели, естесственно были несколько ошарашены (у нас был 4 с). После некоторых разбирательств координатор заверил нас, что на сервере стоит правильный TL (4 с.), и ошибка именно в условиях. Как это произошло? Автор задачи просто решил потестировать неверные решения на полигоне и с этой целью установил TL 15 секунд. В это время и были выгружены условия. Свой взгляд на проблемы участников с кэшем я описал выше.
3) Порядок задач в Div2 — без комментариев. Скажу только что инициатива убрать отметки "Div1 only" из задач первого дива исходила от нас — мы считаем, что это ставит в неравные условия участников онсайта и Открытого Кубка.
4) Провайдер с DDoS-атакой — эта проблема позволяет нам разве что спать спокойно, потому что благодаря ней раунд заведомо был обречен стать нерейтинговым.
Резюмируя всё выше перечисленное, я не хочу искать виноватых и посыпать голову пеплом. Буду действовать конструктивно — выскажу предложения, как сделать так, чтобы подобные проблемы были невозможны в будущем.
Самый забавный факт заключается в том, что это был первый год, когда мы делали задачи в полигоне. Сказать, что это великолепная система — это ничего не сказать, но всех вышеперечисленных проблем можно было бы избежать, если бы отгрузкой условий и тестов, как и в прошлые годы, я занимался самостоятельно. Отсюда можно сделать косвенный вывод о том, что в системе не совсем продуманы некоторые моменты. Постараюсь их изложить, ни сколько не претендуя на полную объективность и не требуя от разработчиков мгновенной реакции — повторюсь, система итак сделана на высочайшем уровне и низкий поклон её авторам за их труды.
При внесении коммита должна быть технология ранжирования его значимости с соответствующим ей уведомлением по e-mail. Конечно, можно самим договориться о том, чтобы писать "CRITICAL!!!" перед описанием коммита и решить эту проблему вручную, но людям свойственно забывать такие вещи (особенно в 4 утра), а простой спойлер мог бы напомнить им об этом.
Необходима система ранжирования ревизий, с явным уведомлением всех авторов об изменении статуса. Предполагается, что только владелец контеста (или те кому он даст такие полномочия) может указать, является ли текущая ревизия финальной или она Beta. В этом случае при выгрузке пакета будет ясно, можно ли использовать данный пакет в контесте или нет. В случае изменения статуса задачи — рассылка критичным сообщением о необходимости скачать обновленную версию пакета.
Другой вариант пункта 2 — уведомление владельца контеста (возможно с checkbox) о скачивании пакета задачи другим участником, это позволит авторам задач проконтроллировать, что их задача была выгружена в корректной ревизии. Как это контроллировать вручную? Я мог бы конечно потребовать от координатора Кубка отчитываться о выгрузке каждой задач передо мной лично, но, согласитесь, это даже звучит весьма грубо, а высказывать такие требования у меня бы просто язык не повернулся, к тому же это всё равно не исключило бы человеческий фактор.
Что касается самого Открытого Кубка — меня ещё в прошлом году (это был первый ГП Приазовья с моим авторством) сильно смутило то, что ни до, ни во время проведения контеста, авторы задач не могут получить никакой информации, кроме той, что доступна обычным болельщикам. Если бы мы увидели первое решение по задаче E сразу, то тесты были бы обновлены ещё на 2-м часу соревнования, и пострадавшей оказалась бы только одна команда. С условиями 2-го дива и TL в F ситуация аналогична. Учитывая, что мы одновременно проводили онсайт, а это не только контест, но и огромная организаторская работа, я не считаю возможным постоянно выходить на личный контакт с координатором и контролировать таким образом ситуацию на Открытом Кубке. Если бы мне не требовалось для этого списываться с координатором по ICQ, а у меня и других авторов контеста был доступ к соревнованию на ejudge как до, так и во время его проведения, безусловно мы бы всё проконтролировали также, как это всегда и делается на онсайте. Это ни в коем случае не претензия в сторону организаторов Открытого Кубка — просто ещё одно конструктивное предложение.
Я старался быть объективным, надеюсь, что в значительной степени мне это удалось. Как я и писал в самом начале — я не снимаю ответственности с себя ни за одну из проблем (разве что с фиктивной DDoS-атакой), и все предложения высказаны исключительно ради конструктива, а не с целью оправдать себя.
P.S. Всё вышесказанное является исключительно моим личным взглядом на ситуацию, и у других авторов контеста может быть другое мнение.
Насчет задачи F: даже если ТЛ на сервере стоял и правильный, 4 секунды, решение за O(NM) мы все-таки пропихали, при том на Java.
Если не трудно, прикрепи код — протестируем у себя и на полигоне ради интереса.
Код под спойлером.
На полигоне проходит и с запасом (700 мс.), у нас тоже скорее всего — не могу проверить пока.
На мой взгляд зарезать ограничения по времени уже было некуда, тесты там точно нормальные — видимо стоит признать не слишком удачной саму задачу.
Вообще, у этой задачи трудная история. Изначально у автора было решение со сложной неквадратичной асимптотикой, не зависящей от K, и естественно другие ограничения. Но при тестировании выяснилось, что от O(NM) оно отличается менее чем в 2 раза, кроме того результат сильно колебался в зависимости от деталей реализации — скрытая константа оказалась слишком высока.
В итоге мы приняли решение задачу упростить — и на мой взгляд не ошиблись. Гораздо глупее выглядела бы ситуация, если бы проходили и решения с неквадратичной асимптотикой и решения за O(NM), чем текущая ситуация, когда подавляющее большинство решений всё-таки имели правильную асимптотику O(MK).
Теперь понятно, почему не прошло решение по F, работающее 10 секунд. А то я все удивлялся, как это на сервере в 15 не укладывается.
Я считаю, что уже давно можно было научить ejudge автоматически забирать из Полигона последний пакет по задаче. У Полигона есть соответствующий API. Это позволило бы не допустить первого бага и значительно сократить время на срочный фикс. У нас задачу можно привязать к конкретной ревизии или указать стратегию "брать последнюю ревизию".
Я считаю, что тестирующая система должна в своем интерфейсе показывать ту информацию по задаче, которой она владеет и которую она использует. В первую очередь имена файлов и ограничения по времени/памяти должны браться из настроек задачи из глубин системы и отображаться в интерфейсе. Это единственный вариант при котором участник может быть уверен, что в системе установлен определенный TL/ML. Все мы знаем, что бывает так: условия правятся в последний момент и рассылаются такими письмами: "Условия задач...", "Финальная версия условий!", "Финальная версия условий. ИСПРАВЛЕНО!". Координаторов вполне может что-то перепутать. Поэтому лучше всегда выкладывать официальную электронную версию и публиковать TL/ML из недр системы.
Конечно, авторы контеста должны иметь менеджерский доступ на контест, чтобы иметь возможность быстро прореагировать.
По поводу расширить мета-информацие ревизии и коммиты — дело хорошее. Мы это дело обмозгуем и что-нибудь заимплементим.
А можно подробнее про API полигона? Где про него можно почитать?
Разве участники не могут сами расставить эти отметки, посмотрев на задачи обоих дивизионов?
Могут, но убрать Div1 Only — это лучше чем не делать ничего) Можно, конечно, ещё переименовать задачи во 2-м диве, но это уже слишком :)