ICPC（互联网内容提供公司）正在开发一款名为“Quiz Millionaire Attack”的杀手级游戏。这是一款通过互联网进行的问答系统。你作为一名工程师加入 ICPC，负责为该系统设计客户端与游戏服务器之间的协议。由于分配给服务器的带宽非常有限，因此必须尽可能减少客户端与服务器之间交换的数据量。此外，所有客户端在问答环节中必须保持良好的同步，以实现同步游玩。特别需要注意的是，接收数据包的延迟问题。

为了验证你的协议是否满足上述要求，你决定模拟客户端与服务器之间的通信，并计算一场游戏期间交换的数据量。

游戏流程如下：首先，确定参与的玩家和使用的题目。所有玩家使用相同的客户端程序，并且已经下载了题目内容，因此你不需要模拟这一部分。接着游戏开始。第一道题目呈现给玩家，玩家在固定时间内回答。之后呈现第二道题目，依此类推。当所有题目完成后，游戏结束。在每个题目阶段，玩家会被告知其他玩家的操作。在你提交答案之前，你可以知道谁已经提交了答案。在你提交答案之后，你可以知道其他玩家提交了什么答案。

当每个题目阶段开始时，服务器向所有玩家发送一个题目开始的同步数据包，并开始轮询过程。在轮询开始后的每 1000 毫秒，服务器会检查在该时刻之前（严格意义上）是否收到了玩家的新答案，如果有，则向所有玩家发送通知：

• 如果玩家尚未提交答案，服务器向其发送类型 A 通知数据包（描述他人的答案），内容为新收到的答案。
• 如果玩家属于刚提交新答案的玩家之一，服务器向其发送类型 B 通知数据包（描述他人的答案），内容为在该时刻之前（严格意义上）所有其他玩家提交的答案（不包括该玩家自己的答案）。
• 如果玩家之前已经提交过答案，服务器向其发送类型 B 通知数据包（描述他人的答案），内容为新收到的答案。

注意，在上述所有情况下，通知数据包（类型 A 和 B）必须包含至少一名玩家的信息，否则不会发送通知数据包。

当题目开始的同步数据包发送后 20 000 毫秒过去时，服务器会在必要时发送类型 A 或 B 的通知数据包，然后向所有玩家发送题目结束的同步数据包，以终止该题目。

玩家可以在收到题目开始的同步数据包之后、收到题目结束的同步数据包之前回答题目。答案通过答案数据包发送。上述数据包的格式如下表所示。

表 1：题目开始的同步数据包

表 2：答案数据包

表 3：描述他人答案的类型 A 通知数据包

表 4：描述他人答案的类型 B 通知数据包

表 5：题目结束的同步数据包

输入格式

输入包含最多 40 个测试用例。

每个测试用例的第一行包含两个整数 $M$ 和 $N$ ($1 \le M, N \le 100$)，分别表示玩家数量和题目数量。下一行包含 $M$ 个非负整数 $D_0, D_1, \dots, D_{M-1}$，表示每个玩家与服务器之间的通信延迟（玩家 ID 从 0 到 $M-1$）。通信延迟在两个方向上相同。

接下来是 $N$ 个描述每道题目提交情况的块。每个块以一行包含整数 $L$ ($0 \le L \le M$) 开头，表示该题目提交答案的玩家数量。接下来的 $L$ 行每行给出一位玩家的答案，由三个字段 $P$、$T$ 和 $A$ 组成，以空格分隔。其中 $P$ 是玩家 ID，$T$ 是从接收到题目开始同步数据包到玩家端提交所经过的时间（毫秒），$A$ 是长度在 1 到 9 之间的字母数字字符串，表示玩家的答案。这 $L$ 行可能以任意顺序给出。

你可以假设所有答案数据包都会在题目开始同步数据包发送后的 19 999 毫秒内（含）被服务器接收。

输入以包含两个零的一行结束。

输出格式

对于每个测试用例，打印 $M+1$ 行，每行包含两个整数。第一行打印服务器发送和接收的数据总量，以空格分隔。接下来的 $M$ 行，按玩家 ID 升序打印每位玩家发送和接收的数据量，以空格分隔。

在两个连续的测试用例之间打印一个空行。

样例

输入 1

3 2
1 2 10
3
0 3420 o
1 4589 o
2 4638 x
3
1 6577 SUZUMIYA
2 7644 SUZUMIYA
0 19979 YASUZUMI
4 2
150 150 150 150
4
0 1344 HOGEHOGE
1 1466 HOGEHOGE
2 1789 HOGEHOGE
3 19100 GEHO
2
2 1200 SETTEN
3 700 SETTEN
0 0

输出 1

177 57
19 58
19 57
19 62

253 70
13 58
13 58
24 66
20 71

表 1：题目开始的同步数据包，表 2：答案数据包，表 3：描述他人答案的类型 A 通知数据包，表 4：描述他人答案的类型 B 通知数据包，表 5：题目结束的同步数据包