P3892 [GDOI2014] OJ

小 M 是一个勤奋的 ACMer，他利用课余时间刷了很多题目。但他是个很健忘的孩子，经常会忘记自己刷过一些什么题目，所以他想写一个 OJ 来管理自己做过的题目。 经过一个星期的努力，小 M 的 OJ 基本成型，只是还差一个 Contest 的模块没有实现。小 M 觉得这个模块很难实现，所以他希望找你来帮忙。 小 M 告诉你，一个 OJ 的基础元素包括： 1. 题目，可以用 pid 唯一标识，pid 为正整数； 2. 比赛，可以用 cid 唯一标识，cid 为正整数； 3. 用户，可以用 uid 唯一标识，uid 为正整数； 4. 提交状态，可以由 sid 唯一标识，sid 为正整数。 一个提交状态是由 sid、cid、pid、uid 和 result 组成的，分别表示本条状态的提交 ID，所属比赛 ID，题目 ID，用户 ID 以及评测结果。 简单起见，这里的 result 只有 AC、UNAC 和 WAIT 三种状态，分别表示通过、不通过和等待评测。 同时小 M 提出一个比赛模块需要实现以下请求： 1. `createContest cid t pid_1 pid_2 … pid_t` 表示要创建一个比赛，cid 是一个正整数，是这场比赛的唯一标识。 $t$ 表示这场比赛有 $t$（($1\le t\le1000$)）道题目，接下来 $t$ 个不同的整数，表示这场比赛的题目编号。 2. `submission sid cid pid uid result` 该条状态的 sid 要么之前没出现过，要么以前出现过，但是被 rejudge 了。 result 为 AC 或者 UNAC。 3. `getRank cid uid` 在一场比赛中，所有有提交的用户都应该算在排名内（包括被 rejudge 的提交），用户的排名按照通过的题目数从大到小排序，如果题目数相同，则按随机顺序排序。 该指令需要统计用户 uid 在 cid 这场比赛中的通过目数，最高排名以及最低排名。 值得注意的是，用户 uid 在 cid 这场比赛中同一道题目的多个通过记录只算一次。 输出格式为：`uid solved highest lowest`。 分别代表用户 ID，通过题目数量，最高排名以及最低排名，其中 $\mathit{highest}\le\mathit{lowest}$。 4. `rejudge sid` 重测以 sid 标识的提交记录，即将该记录的 result 改成 WAIT。

第一行三个整数 $\mathit{pcnt}$、$\mathit{ucnt}$、$m$（$1\le\mathit{pcnt}\le5000,1\le\mathit{ucnt}\le5000,1\le m\le3\times10^5$），分别表示 OJ 有 pcnt 道题目，ucnt 个用户以及 m 条请求。 pid 的范围是 $1000\sim1000+\mathit{pcnt}-1$，uid 的范围是 $1\sim\mathit{ucnt}$，cid 的范围为 $1\sim50$，$1\le\mathit{sid}\le m$。 接下来有 $m$ 行，每行一个请求，请求为题述四种请求之一，请求需要按输入顺序执行。 你需要注意以下几点： 1. 对于 `createContest` 请求，保证 cid 不会与之前的 createContest 的 cid 重复。 2. 对于 `submission` 请求，在此请求前，保证比赛 cid 已经创建，题目 pid 是该场比赛的题目之一。 3. 对于 `getRank` 指令，在此请求前，保证比赛 cid 已经创建，用户 uid 至少在该比赛中有一个提交记录。 4. 对于 `rejudge` 指令，在此请求前，保证存在以 sid 标识的提交。

对于每一个 `getRank` 请求，根据要求输出用户 ID，通过题目数量，最高排名以及最低排名，整数之间用一个空格隔开。

对于 $20\%$ 的数据，$1\le\mathit{pcnt},\mathit{ucnt},m\le100$； 对于 $50\%$ 的数据，$1\le\mathit{pcnt},\mathit{ucnt}\le2000,1\le m\le50000$； 对于 $100\%$ 的数据，$1\le\mathit{pcnt},\mathit{ucnt}\le5000,1\le m\le3\times10^5,1\le\mathit{cid}\le50$。