Начало.
Всё началось с того, что где-то осенью этого года я окончательно забил заниматься олимпиадным программированием, но не закончил придумывать задачи для данных мероприятий. (Краткость, сестра...)
Четвертьфинал.
Первое серьёзное мероприятие, в котором я принял участие с сентября года в роли жюри, был четвертьфинал Северо-Западного региона. Я радостно прибежал на собрание жюри, самое удивительное для меня было, что моё присутствие там почти никто не удивило. Там я предложил несколько неплохих задач, а также ту, которую я придумал на месте, как это ни удивительно — взяли ту, которую я только что придумал.
Собрание жюри полуфинала.
Итак, прошёл четвертьфинал, на котором я налажал с некоторыми тестами (я упустил некоторый случай, а теста у меня против этого не было), за что на меня частично взъелось ИТМО 1. Я их не до конца понимаю — они же выиграли четвертьфинал... Немного обиженный и пристыженный я ждал момента исправиться. И вот он наступил! Мне прислали долгожданное письмо, в котором меня приглашали на встречу жюри полуфинала. Взяв задачи, которые были придуманы ещё к четвертьфиналу, а также придумав ещё одну задачу за день, я пошёл на собрание.
Долго-долго мы тужились, и в конце концов надумали проблемсет. К сожалению, у меня опять не взяли более-менее интересные задачи, пришлось довольствоваться тем, что взяли какую-нибудь задачу. Поэтому эти задачи, видимо, будут предложены на некоторый раунд "codeforces". Она же и была будущей задачей H. Сложнее жюри удавалось придумать названия к задачам, чтобы покрыть буквы латинского алфавита от A до K, к некоторому удовольствию, название моей задачи можно было варьировать, главное, чтобы оно было вида "*drome".
И вот пришёл облом.
Спустя все прошедшие четвертьфиналы, выяснилось, что некоторые задачи уже повторяются — что не есть хорошо. Поэтому собрали срочное заседание жюри, на котором достаточно быстро сообразили ещё задач. Теперь всё оставалось за малым. Надо было подготовить задачу.
ГиперДром.
Задача оказалась не столь простой, сколь я ожидал. Не в плане решения, а в плане подготовки. Я достаточно шустро её подготовил, но потом пошло-поехало. Сначала, мне предложили немного изменить идею задачи. Ну, ничего, подумал я, зато задача стала более естественной. Окей. Научился отличать TreeSet от HashSet. Но не тут-то было...
ГиперДром и бурундук.
Пришёл Burunduk1 и меня расстроил своими быстрыми решениями, что проходил не только map, но и бинарный поиск. (Правда, по понятным причинам.)
Далее на меня снизошло озарение — плохо, если проходит map на C++, так как это асимптотически не является верным, но если map не должен проходить, то и hashmap не должен проходить. Поэтому в срочном порядке придумывалось решение, которое бы работало за приблизительно такую же асимптотику, что и решение с hashmap. С этим всё-таки справились. Далее я долго и упорно подгонял ограничения, чтобы проходило только это решение. Я справился — удалось завалить даже решения Сергея, что не могло не радовать.
Облом-2.
После вот такого долбания с задачей мне сообщили, что это очень хорошо — неасимтотическая оптимизация. Но в таком виде не хотелось давать, так как было неизвестно, какие инвокеры в регионах, а, значит, нельзя быть уверенным, что там процессоры настолько хорошо выполняют последовательные пробеги по массиву. Поэтому пришлось опустить ограничения, чтобы проходило почти всё что угодно. Почти...
Воскресенье. 2.12.2012 г. 10:10-15-10.
Уже очень хотелось спать. Я не так часто встаю так рано. Но, переборов это желание, я подключился к тесной компании, которая находилась в комнате жюри. И сделал не зря — меня почти сразу осчастливили талончиком на питание в столовой. :-)!
Petr писал свой блог. Меня удивлял следующий факт, когда в блоге появлялась информация об ошибке какой-то команды, их accepted не заставлял себя ждать... Также выяснилось, что @niyaznigmatul постит в свой твиттер, некоторые люди возмутились вплоть до того, чтобы дисквалифицировать команду, но как и ожидалось — это было провокация оппозиции.
Пока всё это происходило elizarov писал разбор задач. Я в какой-то момент присоединился... Пытались придумать совсем простое решение к задаче G (Great Deceiver), но справились написать правильное решение только с какого-то раза...
Шоколадка и еда.
elizarov и Petr поспорили друг с другом на две шоколадки — сдаст ли кто-нибудь 11 до заморозки и сдаст ли кто-нибудь всё. Судьба первой шоколадки решилась до обеда. ИТМО 1, можно сказать, развело Романа на шоколадку, притом очень неожиданно — они сдали 11 задачу за 2 минуты до заморозки. После обеда выяснилась судьба второй шоколадки. Счёт: 1-1. Никто не покупал шоколадку.
Закрытие.
И вот настало время закрытия. Мы, жюри, были хранителями тайны. ;-)! Эта фраза, а также ещё множество остальных, у бывалого жюри вызывало истерику — они уже раз в 20-й слышат эти речи.
Я был удивлён, что меня вызвали на сцену. Конечно, было смешно, что я, получается, отдувался за часть жюри, которая находилась не в Питере, так как до следующего присутствующего, произнесли фамилий 5.
Ну, а про песенку-"чо-чо" Вы и сами слышали.
Пьянка после закрытия.
Естественно! Как же могло обойтись без пьянки — ведь команда нашего университета опять выиграла. Вот cerealguy и niyaznigmatul осушили на двоих кубок полный шампанского. После этого залпа, ребят явно повезло...
Пока их везло, я попытался безуспешно поднять Alex_KPR, в то время, как он меня поднял достаточно много раз. А также нашёл у pashka на столе радиоуправляемый "Range Rover" (Радиоуправляемые машинки являлись подарком серьёзному техническому комитету.) и пооббивал ей стенки на нашей кафедре. На удивление — она не развалилась. :-)!
Заключение.
В-общем, на этом для меня закончился NEERC-2012. Мне понравилось. Уж лучше, чем в прошлом году, когда я был волонтёром.
Спасибо всем, кто это дочитал до конца.
Удачи. Возможно, ещё увидимся. Командам желаю удачи на финале.
Был ли anti-Java-Hashmap тест на задачу H?
На самом контесте не было.
А почему? Он же, вроде как, очевидный:
Берем код Грея для 18..20 бит, генерируем 10^5/2 элементов. Теперь, когда нам код Грея говорит менять i-ый бит, мы добавляем символ char(i) и char(i+32) для двух стандартных вариантов ([a..zA..Z] и [A..Za..z], два разных теста). Получаем квадрат. Решение Samara SAU 2 получает законный TLE.
Я не знаю, где Вы получили квадрат. Решение вообще не зависит от типа битмасок. И количество битмасок не может превышать длины строки.
Дело в том, что хешкод по версии Java от Long это ксор старшей и младшей части. Можете удостовериться. Таким образом, я строю пример хеш-коллизии размером 10^5/2. Хеш-мап очевидно ляжет от такого.
Вот если взять вот этот простенький генератор, сгенерировать им тест и запустить из комплекта решение hyperdrome_halyavin.java или, скажем, hyperdrome_va_hashmap.java, можно смело идти пить чай, вернуться и только тогда оно досчитает. Эти решения на самом деле работают за квадрат.
Я не заметил, на CF новая мода минусовать успешные челенджи AC-решений?
Ты не в тренде :)
Зачем делать тест против конкретного языка? Это поставит участников в неравные условия.
А участников ставит в равные условие существование теста, который валит AC-решение одного из них?
Причины падения ракеты на Нью-Йорк никого особо не волнуют.
Язык — это инструмент, со своими недостатками и преимуществами. Надо их знать и уметь использовать/обходить. Например, я же не ору, что в Java/Python встроенная длинка. Либо пишу сам (что тратит время), либо пишу на одном из них (что сложнее, потому что не основной язык).
Или, например, не жалуюсь, что
map::operator[]
создаёт элемент при любом обращении, из-за чего получили бревно на полуфинале. Ну, особенность, надо знать.А то, что в Java стандартные алгоритмы работают за линию/квадрат — её личные проблемы. Другое дело, что в промышленном случае таких тестов, скорее всего, не встретится
Во-первых, вопрос был в том, почему надо делать тест только против одного языка. Если уж делать, то против всех доступных на контесте. Иначе сиди и гадай, против какого языка сегодня жюри решило сделать тесты. Во-вторых, я считаю подобные тесты довольно бессмысленными. Ну начнут все писать свою обертку над long'ом со своим собственным hashCode(), что с того?
Во-первых, я не умею строить такой же тест против кода вижака для хеша инта
с последующим хешированием long long как ксор хешей старшей и младшей части.
Во-вторых, я считаю, что если я могу завалить решения, похожие на авторские, но содержащие принципиальную ошибку (использование известной заранее нумерации и стандартного хеша в Java), я это должен сделать.
То, что Вы не умеете строить тест не значит, что его не существует
Давайте всё-таки различать случай "работают за линию/квадрат" и "можно хитрым способом составить тест, на котором они работают за линию/квадрат". Против почти всех реализаций хешей, которые народ пишет на ACM, можно теоретчески составить какой-нибудь тест, который их валит (просто потому что они обычно детерминированные). Зачем выбирать некоторую одну стандартную реализацию и валить её? Это выглядит исключительно как попытка создать людям немножко геморроя.
Объясните, пожалуйста, еще раз решение этой задачи(H), а то в метро не понял (If you know what i mean). Вот мы посчитали суммы на префиксах по модулю два (битмаски + xor). А как дальше с мапой пересчитывать ответ? Что-то думал-думал, не придумал... I'm slowpoke..
Смотрите. Пусть на префиксе 1..i — битмаска maski. Тогда рассмотрим все битмаски на префиксах меньшей длины. j..i — удовлетворяющая нас строка, если maski xor maskj - 1 = 2k, для какого-то k или maski xor maskj - 1 = 0. Чтобы найти ответ — будем в мапе считать количество префиксов такого типа. Когда дошли до префикса i, мы знаем всё про меньшие префиксы — поэтому нам осталось пробежаться в мапе по маскам вида: maski и maski xor 2k, для всех k. И прибавить их количество к ответу.
Вроде понял, попробую дорешать, спасибо
Не за что...
Добрый день. У меня вопрос про задачу Б. Как можно перепроверить ее решение, поскольку я почти уверен в ее правильности.
Спасибо.
Ссылка на тренировку.
Там нет задачи B, видимо потому что она интерактивная. Можно ли где-нибудь дорешать интерактивные задачи NEERC различных годов?
Постараюсь изучить эту проблему. Просто, для меня, это довольно сложно сделать вне PCMS. Вполне возможно сделать контест в PCMS для одной задачи, если это устроит.
А можешь выложить PCMS, который вы использовали, с уже настроенным контестом NEERC?
Интересует именно та версия, которая использовалась на NEERC, и с полностью настроенным контестом.
К сожалению, это сделать намного сложнее...
Ну запаковать все в архив и выложить куда-нибудь вроде narod.ru. Вы вроде бы не копирасты, не так ли? :)
Видимо, тот кто минусует знает, как это сделать. :-)! Лично я сделать, видимо, не в состоянии, чтобы сохранить целостность системы.
Нельзя просто так взять и запаковать PCMS в архив? Пути к компиляторам я сам пропишу, об этом можно не беспокоиться
Постараюсь завтра добавить задачу
По поводу срача с анти-HashMap-тестом: а почему, собственно, вы подняли ограничения, чтобы TreeMap-ы не заходили? Кажется, идея задачи нисколько от этого не страдает. И 100000 было бы вполне достаточно. Контест все-таки не польский.
Асимптотика всё-таки страдает...
ага, квадрат всяко лучше, чем н лог н
Издеваться будете?
Понятно, что в реальной жизни Вы скорее всего не столкнётесь с этой проблемой. Вопрос в другом, считаете ли Вы, что нужно опустить задачи до такого уровня, чтобы они никак не были прикладными?
Ну в целом я считаю, что формат соревнований предполагает, что программа участника должна проходить все тесты, которые подходят под ограничения за правильное время с вероятностью близкой к 1
Иначе контест превращается в "кто угадает, что же имел в виду автор"(Особенно это в последнее время касается хешей строк по mod 2^64)
Вот что Вы подразумеваете под правильным временем? Не каждую операцию можно запихнуть 10^8 раз в секунду.
Время CPU на тестирующем сервере. А Вы?
Хорошо. Тогда почему Вы считаете по ограничениям, что должно проходить, а что нет? Ограничения дают только приблизительную оценку.
Запомнились три задачи с кубка Панкратьева, а именно:
1) Дан (цитирую) случайный граф, найти в нем максимальное паросочетание. Решалась Куном для двудольных графов.
2) Какая-то задача про пересечение отрезков, ограничения 50000, проходил обычный квадрат.
3) Недавняя самая задача про 2^n * n^2.
Ограничения подразумевают, что любой тест, под них подходящий, возможен. Понятное дело, что задача жюри — подобрать такие тесты, которые будут валить ожидаемые неверные решения, что та еще задача )
Но ничего против составленной Вами задачи не имею, мне она понравилась и с такими ограничениями, идея интересная, спасибо)
Ну я считаю, что то, про те решения, для которых известен тест, на котором они долго работают не должны проходить, а решения, которые я не умею валить — должны:)
Если сереьезно, я не считаю, что в данном случае такие тесты против хешмапы должны быть, это вопрос спорный. Другое дело, что мне не нравится, что гарантированный логарифм хотят отделить, от "на большинстве тестов константы, иногда квадрата", а когда это не получается, подают как величайшую доброту жюри.
Задача, впрочем, действительно неплохая получилась.
Откуда оппозиция в программировании? O_o
а вот интересно, "изнутри" заметили, что красивая динамически размораживающаяся таблица на закрытии не совсем соответствовала замороженной во время контеста. Сложилось впечатление, что если в последний час послать сабмит по уже сданной до заморозки задаче, то на закрытии там будет (?), хотя в обычном стэндинге всё останется как было
Впрочем, обычный стендинг тоже был неверным, в нем такие посылки отмечались бревнами.
Я наверное, пишу не совсем туда, куда нужно, но у меня есть некоторое предложение по работе системы размораживания таблицы. А именно, из всех имеющихся посылок команды, в первую очередь нужно размораживать accepted'ы, это дольше сохраняет интригу, а порядок accepted'ов в свою очередь можно выбирать, например, случайным образом, чтобы не было понятно, что какая-то задача открылась раньше, чем другая, именно потому, что по другой вердикт отрицательный. На закрытии задачи открывались просто по порядку.
Еще, мне кажется, что было бы круто, когда у команды accepted, не просто показывать, что она поднимается в таблице, но ещё и показывать, куда она поднимается, это часто содержит в себе некоторое количество интересной информации о том, как неожиданно команды могут переставляться друг с другом из-за хоть сколько-нибудь близкого штрафа.