Помнится, раньше на ifmo.ru было довольно много визуализатиоров разных алгоритмов. Сейчас их нет (по крайней мере, если найти какую-нибудь статью, где есть ссылка на визуализатор, например на http://rain.ifmo.ru/cat/view.php/vis/sorts/linear-2005 , то пишет 404 Not found, ну и через титулку сайта rain.ifmo.ru тоже ничего похожего не~видно). Прекрасно понимаю, что хоть Java-applet, хоть flash сейчас by default не~работают, но, может всё же можно где-то как-то их (визуализаторы) найти и как-то запускать в какой-то специально настроенной песочнице?

Под "header-ами&footer-ами" понимаю описанное тут.

Кажется совершенно логичным использовать именно такой подход, в частности (но не только) в ситуациях, когда хотим в задаче на какую-то структуру данных подсовывать программе участника огромные размеры входных данных, но не~тратить время на их реальное считывание из входного файла, а генерировать в части, написанной жюри, согласно указанным в настоящем входном файле размерам и некоторым seed-ам. Это, по-видимому, лучше, чем когда генератор описывается в условии и требуется, чтоб участники сами его реализовали в своей программе (и потому, что наименее опытные участники не~нагружаются мутной и непонятной им работой, и потому, что наиболее опытные участники получают меньше возможностей не~решать задачу по сути, а искать, как обойти эту суть, изучив особенности генератора).

Но есть ли какие-то стандартные приёмы, сформулированные best practices и т.д. в вопросе того, как лучше поступать, чтоб гарантировать одинаковость генераторов в header-ах&footer-ах разных языков программирования? Или, может вдруг, есть выводы и practices, показывающие, что гарантировать надо не~одинаковость данных, а что-то другое? Есть ли, например, какой-то набор реализаций на разных языках программирования генераторов случайных чисел, о которых с достаточной мерой уверенности известно, что они при одинаковых seed-ах дают одинаковые последовательности?

Правильно ли я понимаю, что в подавляющем большинстве таких задач следует ожидать, что Python будет проигрывать по быстродействию плюсам, паскалю и даже джаве значительно сильнее, чем в среднем? Я ещё не пробовал, но, учитывая "Видимо, глобальная область видимости плохо влияет на выполнение программы", "keep namespace clean" и "Python accesses local variables much more efficiently than global variables.", следует ожидать ведь именно этого? Ведь в задачах с header-ами&footer-ами участник может хранить что-то своё между разными запусками его функций только в глобальных переменных? Или я что-то упускаю?

И вообще, кто что скажет?

Заранее прошу прощения, если вопрос быстродействия Python на олимпиадных проверялках где-то уже обсуждался достаточно подробно и относительно недавно; в таком случае, прошу указать места таких обсуждений.

Сразу уточню, что вопрос меня интересует не столько в применении к CF, сколько в разрезах "как правильно настраивать ту копию ejudge, которую я со-админю" и "что делать мне как тренеру, когда есть ученики, которые лучше всего знают Python (и непонятно, стОит ли заставлять/убеждать их выучить C++), которых надо хоть как-то подготовить к вряд ли победному, но хоть не слишком провальному выступлению на некоем (скажем, областном) туре, проводимом на централизованном (не моём) сервере".

По моим наблюдениям, В_СРЕДНЕМ Python оказывается медленнее C++ в 1,2--3 раза, и это относительно терпимо, если ставить time limit в 3--5 раз выше времени авторского решения.

Однако, ИНОГДА (в частности, в задачах, где очень-очень много используется операция %, называемая также mod) Python оказывается медленнее C++ в добрых 10--20 раз. Увеличивать TL аж настолько я не_хочу, даже когда имею такую административную (техническую) возможность. (Или, может, дело не в mod... Если кто-то (значительно более, чем я, шарящий) захочет помочь, начиная с выяснения первопричины -- дам права на своей копии ejudge; judge set -- вообще без проблем, более глубокие -- смотря по обстоятельствам.)

Настолько резкие проседания на конкретных задачах -- они вообще лечатся на стороне сервера? Если да, то как? (вроде есть какой-то специальный Python? Кажется, pypy? А он нормально взаимодействует с ejudge? есть какие-то особенности, которые надо изучить перед тем, как его ставить?) И принято ли их лечить на именно тех серверах, которые используются на украинских областных (в централизованном варианте) и финальных этапах? (Не_окажутся ли усилия по нивелированию этой проблемы на нашем сервере жесточайшей медвежьей услугой тем участникам, которые потом будут писать на другом сервере?)

UPD1: Во Вт 12.03.2019 был разослан обновлённый вариант того документа, в котором явные глюки были исправлены -- см. https://drive.google.com/file/d/0B59CuYKkspcjZlRpUWRzRzNSZFgtM0pPNHBFTGhfcDFTRDNv/view?usp=sharing Прошу прощения, что не обновил это сообщение сразу, как-то забыл.

Есть текст документа о проведении AUCPC (украинских этапов ACM ICPC) -- https://drive.google.com/file/d/0B59CuYKkspcjak1lZWVFWnY3TFYyaTJXQVZpUThTRGJmWjVZ/view?usp=sharing

Дата I этапа -- Сб 13.04.2019.

Правда, там также написана какая-то ересь о том, что в ту же дату 13.04.2019 будет сразу и ІІ этап, но это ведь точно неправда, потому что технически невозможно...

Прошу подтвердить либо опровергнуть мои нижеследующие утверждения о теории позиционных игр. Ссылки на источники, где это объяснено, тоже приветствуются. Но именно источники, где объяснена взаимосвязь или показана её невозможность (либо веские причины для сомнительности), а не просто отдельный источник о чём-то одном и отдельный о чём-то другом.

Мои утверждения коротко:

1. Свед_е_ние пристрастных игр к беспристрастным возможно всегда, пока ограничиваемся выигрышностью / проигрышностью позиций, но не используем ту теорему Шпрага-Гранди, которая позволяет ксорить SG игр и узнавать SG их суммы. Если используем -- использовать свед_е_ние нельзя, и исключений то ли вообще нет, то ли они какие-то очень-очень узкие и странные.

2. Хотя существует алгоритм решения "мизерного Нима", или "Нима в поддавки", в подавляющем большинстве случаев его нельзя обобщить на другие игры тем же способом, которым тому, как обычный Ним обобщается на все игры, решаемые через SG.

Более подробная версия -- под катом.

Хочу использовать в чекере (не интерактивном) длинную целочисленную арифметику (умеренно длинную, при наихудших обстоятельствах до 1000 арифметических действий, значения чисел до 1e100, в среднем и то, и то значительно меньше).

Что тут будет лучшим (с точки зрения best practice) -- писать чекер на питоне или прикручивать длинку к testlib.h ? Есть ли какие-то заготовки на подобные случаи?

Реальный опыт написания чекеров есть только на testlib.h, с питоном вроде бы и теоретически ясно, но всё же буду благодарен за примеры и ссылки на рассказы о подводных камнях (если такие есть).

Есть текст приказа о собственно студенческой ( https://drive.google.com/file/d/0B59CuYKkspcjOWo2RHhuSkNKQ2kwN0dEaGhhMEJTRVo4d0lJ/view?usp=sharing ) и проект текста приказа о школьном дивизионе ( https://drive.google.com/file/d/0B59CuYKkspcjMk9zZTJaSlVmM2EyaU03RG1EUUZnTERPVHpn/view?usp=sharing )

Дата самого этапа -- Сб 21.04.2018

Дата окончания регистрации -- сейчас установлена Сб 07.04.2018; вероятно, будет ещё продлена, но слишком твёрдо на это лучше не~рассчитывать.

Все, в том числе школьники, регистрируются на двух сайтах — icpc.baylor.edu и icpc.org.ua

При регистрации на icpc.baylor.edu, учитывая, что это сезон 2018/19 годов, а сейчас ещё не окончился сезон 2017/18 годов, работают не все возможные способы регистрации. Работает, в частности, выбрать нужную из ссылок

https://icpc.baylor.edu/regionals/finder/ukraine-central-2018

https://icpc.baylor.edu/regionals/finder/ukraine-northern-2018

https://icpc.baylor.edu/regionals/finder/ukraine-eastern-2018

https://icpc.baylor.edu/regionals/finder/ukraine-southern-2018

https://icpc.baylor.edu/regionals/finder/ukraine-western-2018

https://icpc.baylor.edu/regionals/finder/ukraine-southwestern-2018

Только сегодня подписан приказ ( https://drive.google.com/file/d/0B59CuYKkspcjT3BITnJRcWJWX2dpUElCVlpzN3NSNERuRThZ/view?usp=sharing )

Окончание регистрации в этот Чт 23.03.2017, сам 1-й этап в эту Сб 25.03.2017.

Прошу не_минусить МЕНЯ за тормознутость взаимодействия центрального оргкомитета (к которому я не_принадлежу) с министерством.

UPD: Искренне надеюсь, что вот эти методические рекомендации дополняющие местными правилами общие правила ACM ICPC окончательны: https://drive.google.com/file/d/0B59CuYKkspcjMGRhUzcxaGlncG55b2RmY3hmVHFmNTVfLW5r/view?usp=sharing и https://drive.google.com/file/d/0B59CuYKkspcjb0N2RFVseWlzR01Wcmp3bWo2eGp4U0FnOFFr/view?usp=sharing

Какие есть АНГЛОЯЗЫЧНЫЕ бесплатные онлайн-архивы с ОЧЕНЬ ПРОСТЫМИ задачами? Нужен вовсе не олимпиадный уровень, а что-то типа http://informatics.mccme.ru/mod/statements/view.php?id=276 и http://informatics.mccme.ru/mod/statements/view.php?id=208 но с английским языком условий задач.

Если online judge содержит как простые так и сложные задачи (как и упомянутый informatics), НЕОБХОДИМО, чтоб простые были как-то отобраны (хотя бы в каком-то внешнем списке). Аргументацию на уровне "там есть в т ч и простые задачи, если хорошенько порыться" не_предлагать.

Месюра разослал, пока что полуофициально ввиду незавершённости оформления в министерстве, черновик приказа на новый сезон.

Как всегда, разорван между учебными годами (**І этап Сб 16.04.2016**, регистрация должна открыться завтра в Пт 18.03.2016).

На ІІ этап планируется дальнейшее дробление регионов:

Київська, Сумська, Чернігівська, Житомирська --- Північний
Донецька, Луганська, Харківська --- Східний
Дніпропетровська, Кіровоградська, Полтавська, Черкаська	--- Центральний
Запорізька, АР Крим, Миколаївська, Одеська, Херсонська --- Південний
Вінницька, Хмельницька, Тернопільська, Чернівецька --- Південно-західний
Волинська, Закарпатська, Івано-Франківська, Львівська, Рівненська --- Західний

Весьма интересно. Как вообще, так и в разрезе вопроса "есть ли хоть какие-то исследования, как всё это влияет на hash-и и рандомизированные алгоритмы".

https://vk.com/abacabadabacabaeabacabadabacaba?w=wall6_53888

На ACM ICPC есть традиция -- давать за решение задачи шарик. Так что перед staff-ом возникает задача: вовремя узнавать, что куда-то там надо отнести шарик.

Конкретно на нашем 1-ом этапе она усложняется тем, что:

1) команде, которая решила задачу первой, шарик гелиевый, а остальным -- воздушный.

2) Команды у нас сидят по разным аудиториям (не_очень хорошо, но спортзал нам никто не_даст и тем более никто не_будет тянуть в него всю проводку).

3) Админы нашей копии ejudge-а хотят привязку команд к логинам до жеребьёвки, так что из логина нельзя быстро понять, где геометрически находится команда (надо смотреть табличку).

В этих условиях, ситуация уже несколько запутанная, и хотелось_бы её автоматизировать в виде некоей tool-зы, которая будет иметь на входе табличку с соответствием логинов названиям команд и их геометрическому размещению (например, "ауд.126, комп.4", "ауд.129, комп.1"), регулярно перечитывать табличку с текущими результатами, и писать в хронологическом порядке, какой шарик (с какой буквой задачи и гелиевый или обычный) куда отнести.

1) Есть ли что-то готовое, которое реально патчить под наши условия?

2) Если писАть самому, то как лучше всего вытягивать из ejudge-а данные о фактах успешных решений?

3) Какие тут вообще могут быть неочевидные моменты? Пока что я вижу два: (А) rejudge-и; (Б) носить_ли шарики во_время заморозки? (вроде_ж надо не_носить?)

UPD: учитывая, что админить буду не_я, предпочтительны варианты, работающие через сеть не_на компе где собственно ejudge, и знающие максимум логин/пароль, которым представлены права JUDGE_LOGIN и VIEW_STANDINGS, но не_дающие прав как-то влиять на ход соревнования.

Включён ли Python ОФИЦИАЛЬНО в языки ACM ICPC?

А то вроде как в куче мест (например: https://vk.com/andrewzta?w=wall351122_1729%2Fall ; http://codeforces.net/blog/entry/15018#comment-199826) есть упоминания в стиле "Вводят питон на ICPC, но без гарантии, что можно будет на нем что-нибудь решить", но упоминаний на icpc.baylor.edu не_вижу.

Интересует в первую очередь сезон 2015-16, потому как в Украине ближайший (25.04.2015) тур — четвертьфинал Украины, он же предварительный перед четвертьфиналом мира сезона 2015-16. Но есть ли по этому поводу вообще хоть что-то официальное?

Появился текст приказа — см. https://drive.google.com/file/d/0B59CuYKkspcjcnJ4MDFDeW5qZUZfcF96Q0RnUFo5SVAtRG1r/view?usp=sharing

Всё примерно аналогично прошлому году.

I (областной) этап Сб 25.04.2015.

UPD 24.04.2014: Напоминаю, что послезавтра (Ср 16.04.2014) -- вроде как последний день регистрации на icpc.baylor.edu , а сам тур будет Сб 26.04.2014.

UPD 27.01.2014: Пришёл по официальным каналам текст приказа, см. https://docs.google.com/document/d/1C95TiSSi7y7w6nwN_vSXiijY3jITvdTl_zSYnz-Tsmw/edit?usp=sharing

=== старый текст ===

На днях координаторам 1--2 этапов пришло письмо от В. И. Месюры, с позравлениями насчёт выделения 6 мест SEERC-у и предложением обсудить сроки проведения 1-го (областного) этапа следующего сезона. Поскольку на то не было разрешения, само письмо публиковать не буду. Отмечу лишь, что к обсуждению предлагались лишь сроки 1-го этапа, а прочие обсуждения — моя личная отсебятина.

Я на самом деле не знаю, буду ли я лично не то что на финале Украины, а даже и на полуфинале (четвертьфинале мира). Так что просто довожу информацию, а формы обсуждения между собой и формы обсуждения с В. И. Месюрой пусть заинтересованные лица выбирают сами.

Собственно моё письмо координаторам 1--2 этапов (украинский — оригинал, русский — Google-перевод, за качество не отвечаю)

Почему-то нигде не нашёл внятной доки, как превращать html-файлы с текстами условий задач, генерируемые Polygon-ом, в xml-файлы, из которых ejudge может отображать условия участникам. Ткните, пожалуйста, в какую-нибудь конкретную доку.

Или там всё совсем грустно, постоянно меняется и лучший способ — каждый раз переписывать на коленке свою прогу, парсящую первое и генерящую второе?

В Visual C++ (как в полной, так и в Express-версиях) есть возможность переключаться между стандартной Debug-конфигурацией и стандартной Release-конфигурацией. Один и тот же код при запуске в этих разных конфигурациях ведёт себя по-разному во всяких мелких вопросах, главным образом — проверках. В общем и целом, всё неплохо продумано, очень помогает и отловить ошибки во время отладки (Debug), и получить эффективный окончательный код (Release).

Но иногда эти проверки замедляют выполнение программы не в 2---10 раз (что почти всегда терпимо), а асимптотически. Например, каждая операция с пирамидой (priority_queue), которая вообще-то требует действий, начинает полностью проверять свойство "каждый отец больше-равен каждого из своих сыновей" по всей пирамиде, что естественно требует Ω(size).

Я далёк от мысли считать, будто эта проверка основного свойства пирамиды всегда лишняя и Microsoft дураки что включили её в библиотеку. Она бывает полезна — главным образом, когда сам не заметил, что перегрузил где-то operator < так, что он не оказался одновременно полным, антисимметричным и транзитивным, и вследствие этого нарушились нужные свойства пирамиды.

И всё равно порой возникает ситуация, когда я абсолютно уверен в правильности перегрузки operator < и в правильности работы именно пирамиды, но не уверен в других вещах. Как следствие — хочется подольше потестировать всё это в Debug-конфигурации, но не хочется ждать в сотни или тысячи раз дольше ради проверок пирамиды, в которой я и так уверен.

Можно ли штатными средствами отключать одну лишь только проверку основного свойства пирамиды? Я примерно представляю, как этого добиться, тупо нагло меняя текст функции void _Debug_heap(_RanIt _First, _RanIt _Last, _Pr _Pred) библиотеки alrorithm, но можно ли обойтись без такого неприличного действия как самому тупо нагло менять текст функции из стандартной библиотеки?

В принципе интересуют и другие аналогичные вопросы более тонкой (чем Debug/Release) настройки подобных проверок.

(Прошу прощения, тут больше я тупил, чем было реально трудностей... Вопрос можно считать закрытым)

Пусть в некотором категорически не олимпиадном, но и не шибко практическом проекте появилось желание сделать такую штуку: создать некий класс Two_ostreams, чтоб потом можно было создать его экземпляр как-то в стиле Two_ostreams log_and_view("log.txt", cerr);, и чтоб каждый вызов log_and_view << a+b, посчитав сумму a+b, писал её сразу и на cerr, и в файл log.txt.

Казалось бы, элементарно:

class Two_ostreams
{
protected:
	ostream &ostr1, &ostr2;
public:
	Two_ostreams(ostream &o1, ostream &o2) : ostr1(o1), ostr2(o2) { } ;
	template<class D> Two_ostreams &operator << (const D &data) 
	{
		ostr1 << data;
		ostr2 << data;
		return *this;
	}
};

Да не тут-то было: оно работает с примитивными типами, для коих перегрузка << стандартна, но всё ломается при попытке использовать вышеизложенный Two_ostreams с классом C, в котором и определяется собственный friend ostream &operator << (ostream&, const C&), и свежеопределённый << используется в одном из методов. Конкретнее, в момент компиляции Two_ostreams ещё нету перегрузки << для C. Полностью переставлять местами, чтобы всё определение C шло раньше всего определения Two_ostreams никуда не годится, т.к. хочется именно использовать Two_ostreams в некоторых методах C.

Это всё вообще имеет красивое решение? или любой способ будет настолько мрачен, что лучше уж везде по два раза повторять flog << blablabla; cerr << blablabla;?

Что-то никто не пишет, напишу сам...

Четвертьфиналы Украины (они же студенческие областные, они же предварительные перед проводимыми в Украине четвертьфиналами ACM ICPC) запланированы на Сб 20.04.2013. В данный момент приказ, наверно, ещё не подписан, но вероятность изменений даты очень мала.

Полуфиналы Украины (они же проводимые в Украине четвертьфиналы ACM ICPC) запланированы на сентябрь. Не смотря на то, что ранее шла речь о том, что прошлый раз сентябрь был исключением и что их вернут в апрель--май.

UPD: Приказ наконец-то появился, скачать можно тут.

UPD: Появилось расписание. Собственно тур с 10:00 до 15:00, но учитывая этап "здравствуйте товарищи", жеребьёвку и т.д. приходить надо раньше. На сколько раньше -- решает местный оргкомитет 1-го этапа.

Кажется, в данный момент имеет место проблема с Полигоном ( http://polygon.codeforces.com ).

UPD: Текущая проблема — в конце текста

Конкретно это проявляется в том, что одна и та же копия ejudge импортирует пакеты, созданные Полигоном ранее, но не импортирует созданные именно сейчас. Более того: по одной из задач (номер на Полигоне 5477) старый (8-й) пакет импортировался, а после абсолютно несущественных изменений (на уровне добавить пробелы в условие) и пересобирания пакета новый (9-й) пакет не импортируется.

И заодно: было бы неплохо, если б [admin:MikeMirzayanov] (или кто-то другой из разработчиков) завёл централизованный блог, куда было бы официально положено писАть о всех подобных вещах.

UPD: более конкретно, при попытке импорта архив выкачивается, а потом пишет, например, так:

zip_open_func: failed to open ZIP '/home/judges/000005/download/ck-2012-13-ii-d-15$linux.zip': Zip archive inconsistent
Failed to open zip file '/home/judges/000005/download/ck-2012-13-ii-d-15$linux.zip'

Хотя с архивами старых пакетов вроде бы всё работает

Проблема от 15.05.2013: при выборе из списка стандартного чекера ncmp.cpp при создании пакета пишет вердикт "PackageException: Can't compile checker"

Проблема от 14.07.2013: вообще невозможно продолжать править существующие задачи. Пишет "Can't open problem <название-задачи>. It is possible that there conflicts found. Try "Resolve conflicts" option". Хотя я уверен, что как минимум по большинству моим задачам никто ничего не правит, скорее даже вообще никто ничего не правит. Ну, и ни <<"Resolve conflicts" option>>, ни <> тоже не помогают.

Пробовал под Chrome 28.0.1500.71, Firefox 22.0

Проблема от 06.01.2015: Опять проблема, примерно аналогичная проблеме от 14.07.2013. Конкретнее: при попытке зайти в задачу (конкретно задача 7581) пишет Can't open problem <problemname>. It is possible that there conflicts found. Try "Resolve conflicts" option. Попытка нажать Resolve conflicts приводит к сообщению No conflict found, но ничего по сути не меняется. Попытка нажать Discard приводит к попытке перехода по адресу https://polygon.codeforces.com/edit-stop?id=...&ccid=..., где показывает тупо абсолютно пустую белую страницу и ничего не происходит.

Вступление:

ejudge scoring checker — балл за задачу (или за каждый тест) выставляется проверяющей программой. Чекер может оценивать тест в любое количество баллов от 0 и до максимального балла за данный тест. ( http://ejudge.ru/wiki/index.php/Serve.cfg:problem:scoring_checker )

Суть вопроса:

1) Может ли кто-то выслать/расшарить несекретный рабочий пример такого чекера? Желательно, совместимого с testlib, используемой на Polygon.

2) Возможно ли вообще всё это настроить, если есть ejudge version 2.3.24, и к ней есть доступ через cgi-bin/serve-control но нету доступа к командной строке? Если возможно — как?

Вопрос вряд ли имеет прямую практическую ценность, но всё же...

Мне довольно долго казалось, что в АВЛ-деревьях правила выполнения поворотов совершенно жёсткие и не допускают разночтений (когда какой поворот выполнять).

Только что обнаружил, что в случае с удалениями это не всегда так. Пусть есть дерево:

         5
     3         8
             7   9

(у корня 5 слева — лист 3, справа — поддерево с тремя вершинами).

Удаляя вершину 3, получаем ситуацию

        5
               8
             7   9

к которой возможно применять хоть левый поворот, получая

           8
     5         9
       7

хоть право-левый, получая

          7
     5         8
                 9

1) Правда ли это?

2) Есть ли ещё какие-то случаи, когда правила работы с АВЛ-деревьями допускают неоднозначность? (кроме только что упомянутого и кроме того, что при удалении можно брать либо наименьший элемент правого поддерева, либо наибольший элемент левого)

См. https://docs.google.com/document/d/1g4ntoEf9MdLbgrP2iFyC3XF1ytCuhEq2EAzcVH7CryQ/edit

Замечания, предложения и вопросы приветствуются.

Я хочу высказаться не как в основном фиолетовый участник, а как препод, работающий с учениками и студентами — олимпиадниками разного уровня продвинутости (от самого начального до дипломов на ученическом Всеукре / полуфинале Украины, он же четвертьфинал мира).

Как мне кажется, на протяжении последнего примерно полудесятка раундов в большинстве (едва ли не всех кроме Codeforces Round #141 (Div. 2) от 27.09.2012) имели место излишне сложные задачи A, B Div. 2. Насколько я понимаю, почти все эти раунды готовили молодые люди, полные задора и желания выдать интересные задачи. Но, как по мне, проект codeforces должен определиться: или он становится элитным и не массово-образовательным даже в части Div. 2 (и явно объявляет об этом, и полностью отказывается от задач, решаемых одной формулой / одним простым for-ом без массива, и многие преподы включая меня ищут другие ресурсы для начального уровня), или восстанавливает уровень задачи A, B Div. 2 таким, каким он был ранее (более простым). А то сейчас с одной стороны происходит не привлечение новых людей, а отпугивание, а с другой — явных объявлений об изменении политики как-то не наблюдается, и утешительные задачи время от времени таки появляются. И что делать преподам — непонятно.

Разумеется, я не призываю "уменьшать под мой фиолетовый уровень" планку Div.1. Я призываю только определиться с политикой насчёт A, B Div. 2.

Разумеется, я приглашаю к дискуссии всех участников codeforces, но прошу указывать объём именно преподского опыта.

Извините за боянистое название, но есть задача и тупо не знаю ни с чего начинать, ни к какой теме отнести. Вот, CF100--C codeforces.ru/contest/140/problem/C чем-то частично напомнила -- я и вспомнил да решил спросить старших и более опытных товарищей.

Собственно условие. Точнее говоря, это русский перевод. Что он правильно отображает украинский текст каким я его увидел я проверял несколько раз. Но если кому не трудно -- можно перепроверить. Возможно, украинский текст сам является переводом, но насчёт этого я ничего не знаю.

Оный отборочный тур проходил в начале марта 2011. Играла ли эта задача где-то ещё -- не знаю. Спросить непосредственно жюри именно того тура нельзя, потому что нельзя (такова политическая ситуация в отдельно взятом институте последипломного образования). Спросить участников тех отборов -- пробовал, никто из них не решил, жюри изобразило, будто рассказать могли бы, да некогда.