|
|
| Имя входного файла |
стандартный ввод |
| Имя выходного файла |
стандартный вывод |
| Ограничение по времени |
2 секунды |
| Ограничение по памяти |
256 мегабайт |
Перед выпуском VK Messenger'а разработчики из IT-компании «VK», как и положено, убеждаются в корректности работы приложения. Проверкой корректности работы систем занимаются тестировщики и QA-инженеры.
Часть функциональных тестов для тестирования смены ников выглядит следующим образом:
- генерируется случайный сценарий взаимодействия пользователей с приложением;
- в приложении симулируется выполнение этого сценария;
- проверяется корректность итогового состояния приложения.
Вам предлагается почувствовать себя в роли тестировщика и реализовать решение, обрабатывающее сценарий без взаимодействия с приложением. Результат обработки сценария затем будет сравниваться с итоговым состоянием приложения.
Каждый сценарий состоит из трех наборов событий.
-
Первый набор состоит из событий вида «в момент времени ti поступил запрос регистрации нового пользователя с ID idi и ником handlei».
Гарантируется, что ID уникальны для всех пользователей приложения. Если выбранный ник никем не занят, регистрация проходит успешно, иначе запрос на регистрацию отклоняется. Во втором случае пользователь с тем же ID может попробовать зарегистрироваться еще раз.
-
Второй набор описывает события вида «в момент времени ti пользователь с ником handlei,1 отправляет запрос на смену ника на handlei,2».
Гарантируется, что для каждого такого запроса ник handlei,1 кому-то принадлежит. Если handlei,2 уже занят каким-либо пользователем, запрос отклоняется, иначе пользователь успешно меняет ник. При успешной смене ника старый ник перестает ассоциироваться с каким-либо пользователем, пока кто-то снова его не займет.
-
Третий набор описывает события вида «в момент времени ti пользователь с ником handlei,1 отправляет сообщение пользователю с ником handlei,2».
Гарантируется, что и handlei,1, и handlei,2 на момент времени ti соответствуют каким-то зарегистрированным пользователям.
Также гарантируется, что никакие два события не происходят в одно и то же время, то есть все ti уникальны.
Вам даны описания всех трех наборов событий. Определите для каждого пользователя, сколько он всего получил сообщений, и от какого пользователя он получил больше всего сообщений за весь сценарий.
Формат входных данных
В первой строке ввода дано единственное целое число T — количество сценариев, которое вам необходимо обработать (1≤T≤100).
Далее следуют T описаний сценариев. Описание каждого сценария начинается с пустой строки, после чего следуют три набора событий. В первой строке описания q-го набора (q от 1 до 3) дано единственное целое число nq — количество событий в наборе, после чего следуют nq строк в указанном ниже формате (1≤n1+n2+n3≤1000; 0≤nq).
- События первого набора задаются в формате «REG idi BY handlei AT ti».
- События второго набора задаются в формате « CHANGE handlei,1 TO handlei,2 AT ti».
- События третьего набора задаются в формате «SEND FROM handlei,1 TO handlei,2 AT ti».
Моменты событий ti — целые числа от 1 до 109. Также все idi — целые числа от 1 до 109, а handlei — строки из маленьких латинских букв длины не более 10.
Гарантируется, что в каждом наборе входных данных все ti различны. Гарантируется, что успешно зарегистрированный пользователь не предпринимает попытки зарегистрироваться еще раз.
Формат выходных данных
Для каждого сценария выведите требуемую статистику для каждого пользователя.
В первой строке статистики выведите целое число q — количество зарегистрированных пользователей. В следующих q строках выведите статистику для каждого пользователя в порядке возрастания их ID в формате
«<id> RECEIVED <total> TOP <counttop> FROM <idtop>», где total — суммарное количество полученных пользователем сообщений, idtop — ID пользователя, от которого он получил больше всего сообщений, а counttop — само количество сообщений, полученных от пользователя idtop.
Если у некоторого пользователя есть несколько собеседников, отправивших ему максимальное число сообщений, выведите в качестве idtop минимальный из их ID. Если пользователь не получал сообщения, считайте counttop равным 0.
Пример
| Стандартный ввод |
Стандартный вывод |
2
4
REG 1 BY sh AT 10
REG 2 BY sh AT 11
REG 3 BY qwerty AT 12
REG 2 BY shvetz AT 15
2
CHANGE sh TO shvetz AT 13
CHANGE shvetz TO sh AT 18
4
SEND FROM shvetz TO qwerty AT 14
SEND FROM shvetz TO shvetz AT 16
SEND FROM shvetz TO qwerty AT 17
SEND FROM qwerty TO sh AT 19
2
REG 1 BY a AT 10
REG 2 BY b AT 11
4
CHANGE a TO c AT 14
CHANGE b TO a AT 17
CHANGE c TO a AT 20
CHANGE c TO b AT 23
10
SEND FROM a TO b AT 12
SEND FROM b TO a AT 13
SEND FROM b TO c AT 15
SEND FROM b TO c AT 16
SEND FROM a TO c AT 18
SEND FROM a TO c AT 19
SEND FROM c TO a AT 21
SEND FROM a TO c AT 22
SEND FROM a TO b AT 24
SEND FROM a TO b AT 25
|
2
1 RECEIVED 2 TOP 1 FROM 1
3 RECEIVED 2 TOP 2 FROM 1
2
1 RECEIVED 8 TOP 8 FROM 2
2 RECEIVED 2 TOP 2 FROM 1
|
Комментарий
Обратите внимание, что ввод и вывод осуществляется через стандартный ввод и стандартный вывод. В случае отрицательного ответа системы проверки заданий по программированию советуем ознакомиться с "Рекомендациями по решению задач по программированию".
Рекомендации к пояснению решения задачи (только для участников 10 класса).
В пояснении к решению задачи раскройте следующие вопросы:
1. Кратко опишите алгоритм решения задачи.
2. По коду поясните назначение отдельных программных структур (функций, процедур, классов, фрагментов кода, выполняющих определенные операции по считыванию, обработке и записи данных) и структур данных, раскройте их роль в реализованном алгоритме.
3. По желанию, можно привести оценку сложности предложенного алгоритма.
Рекомендуемое время пояснения решения 2-4 минуты.