ContestSonic 开发笔记（四）

首先谢罪，因为自从写完（三）之后真的这个就一点也没动过。然后结题论文胡写一通，PPT 测评系统实锤，简直是瞎搞。

最大的工作可能是给题目和赛制建模，但是这个谁都知道咋建……

下面就是最终的（阶段性）成果了……（虽然人尽皆知吧……）

题目类型分类如下：

• 传统型：这个是最基本的输入-输出型，也是最普遍使用的；
• 提交答案型：相比于传统型，省略了代码部分，直接根据输入提交答案即可；
• 交互题：分为函数交互和 IO 交互两部分，主要任务是实现接口，并最小化查询次数；
• 通信题：写两个程序，一个程序处理输入并发送信息给第二个程序，要求通信字节数尽量少，第二个程序实现题目要求功能，两个程序可以互相通信。

赛制如下：

• 赛中无反馈型：根本无反馈，并没有罚时机制；
• 赛中有反馈无罚时型（IOI 型）；
• 赛中有反馈有罚时型（ICPC 型）。

评分规则的话，平均评分可以看成一种特殊的子任务，即分成测试点数目的子任务，每个子任务得分即为总分除以测试点个数。

因为线下比赛采用 CF 赛制的比较少，因此并不考虑（实际上考虑的是可编程题目类型和赛制类型）。

就这样其实统一一下测评 API 看似就完事了……

考虑测评一个测试点，其实大致都是一样的……但对输入输出的控制实现不同。传统题，利用函数交互的交互题和通信题直接重定向输入输出即可，但是 IO 交互的交互题和通信题需要用管道把选手程序和交互库连接起来。提交答案型直接扔到判断过程即可，省略程序运行过程。实现时直接跳过即可。或者为了实现节拍对齐，需要打是否已经测评标记的话，实现全打好即可。

这样对于一个子任务，就是对于多个测试点测评信息的整合，测评一道题就是对多个子任务测评的整合。比如子任务依赖等等需求都在这里加代码。测评比赛就是支持多道题这样……

这样其实很容易通过一些接口实现扩展（最近 Java 上头了……），包括赛制的支持，也可以通过一些参数的配置实现。

一些测评技术，比如 cgroup，JudgeDuckOS，测评端异步交互，测评任务均衡什么的别人比我清楚得多……

可编程题目类型和赛制类型其实就是接口实现，别人会得比我多……

最后这玩意不会实现……我放弃了……

创新创业项目倒是就此截止了，但是闲得没事的时候可能会写写后端什么的。但是更可能写的是爬虫把 Lutece 爬了……或者研究 Lutece 咋写的……

反正最后大概率咕咕咕……wdnmdacm……

以上。