|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
目录
作业描述及分析
背景
栋哥对大家第一次结对编程作业的原型设计感到很满意，为了尽快让同学们使用上软件，于是栋哥花一晚上时间开发了一个点名小程序。但是在上线运行过后，发现了一些问题：
大多数老师习惯在每次上课后或下课前的一小段时间内进行点名。
如果采用全点的方式，在这段时间里，后端服务器需要处理大量的请求，拥塞导致响应速度变慢，给点名小程序带来极差的使用体验。
采用随机抽点的方式，能够有效减少并发量，但是无法保证点名的质量，难以有效抓出没有到教室的同学。
所以栋哥急需大家设计一个算法来解决这个问题，要求能够最小化向后端发送的请求次数，最大化抓出缺勤同学的数量
关于缺勤，大家身边每天都在发生，有许多原因会导致学生翘课，比如熬夜肝Genshin 太困了、课程没意思、不想学习。据调查发现，大学逃课对成绩有负面影响[1]。同理，我们可以认为逃课经常发生在平均成绩靠后的学生上。
[1]楼润平,盛革,杨德锋.大学生逃课对考试成绩影响的实证研究[J].考试研究,2013(04):44-50.
具体要求
定义5门课程，每个课程班级人数为90人，一学期共20次课。每门课程均有5-8位同学缺席了该学期80%的课，此外每次课程均还有0-3位同学由于各种原因缺席
评价标准
代码仓库
duty(不缺勤可是学生的duty啊)
commit记录
重点部分展示
数据集生成
重点：在设计数据集时，怎么设置那5-8人就是最主要的问题，毕竟他们人又多，缺课也多，E就是主要为这个群体“服务”的。所以，如何合理的分布这主要的缺课同学就是一个重点。难点便是寻找一个和现实程度相似性高的分布，并用其来实现缺课学生的随机分布。
实现：
引入绩点机制
- 通过现有数据，通过S-W检验，结合P-P图和Q-Q图，我们近似认为绩点分布具有正态性，并取均值μ＝2.8，由3-σ原则求出标准差σ＝0.4。
- 此处绩点为上这门课前的学生之前的平均绩点
- 在选取缺课学生时，根据绩点的值为其赋予不同的频度，频度越高的在后续抽样中被抽取到的几率相对就大。
算法设计思路
- 主要参数：学生到位情况（1/0），绩点
- 绩点：每个班服从 N ~（2.8,0.4）的正态分布
- 经常缺课的同学：每门课按照既定的“类指数分布”，结合绩点选取n位同学,其中n∈[5,8]
- n位同学缺的课：对于每一个同学，随机从16-20中选取其缺课的节数，再将其缺的课随机分布在20节课中
数据生成样例
1.不同缺课人数下的绩点分布
2.到位数据示例
点名算法
重点：在抽尽可能少的同时保证有效抽点次数最大化
算法设计思路
算法一
- 第一次点名，对绩点低于L的学生进行全点，记录未到学生学号
- 第二次点名，对第一次未到的学生进行点名，将此次到位的学生从记录中移除
- 通过前两次点名，确定潜在的经常缺课学生学号，后续18次点名点这些在记录中的潜在缺课学生
算法二
- 第一次课不点名
- 第二次课开始对之前所有次课的到位情况使用KNN进行分类预测
算法实现情况
1.算法一中L值的确定
通过观察不同课程在设置不同L值下E值的情况，结合数据可视化分析
由折线图可知，五门课程在2.4处有较为一致的最大值。由于各班的绩点服从的分布相同，故可认为L=2.4具有一定的普遍意义。
2.算法一结果
| 课程编号 | 1 | 2 | 3 | 4 | 5 | Total |
|---|---|---|---|---|---|---|
| E | 0.82 | 0.75 | 0.77 | 0.73 | 0.79 | 0.78 |
方差：0.002653
3.算法二结果
| 课程编号 | 1 | 2 | 3 | 4 | 5 | Total |
|---|---|---|---|---|---|---|
| E | 0.90 | 0.90 | 0.88 | 0.83 | 0.84 | 0.87 |
方差：0.005862
两种算法的方差都比较小，可以认为稳定性良好。
Time Eater
1.数据集的生成中，为了通过绩点来合理选取缺课的同学，选择了random.choice(list,num,p），其中，p是从list中选到每一个元素的概率。
一开始，我设想将每一个人的绩点GPA进行4-GPA/4处理后在归一化值作为其概率，但是结果很奇怪，多试几次后甚至发现这时候选取的同学的绩点还服从正态分布（惊呆了😶）。
搞了好一会才发现这个每一个学生的概率过小了，使其相加的时候发生了溢出，导致p的总和不为1（根本就没按概率去选人了属于是）。最后是将不同分数段的人赋予不同的频数，虽然耗费了yi点空间，但还算得出了符合预期是数据集。
2.在算法选择方面，我们一开始也讨论过一些复杂的算法并进行一定的尝试，如一些机器学习算法等，但发现都有些不尽人意，结果反而还不如一些简单的来的好，因此最后确定了上面两种较为简单的算法。
PSP
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
学习进度表
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 130 | 130 | 4 | 4 | 熟悉random库的各个方法，构建基本的数据分布模型，调整模型参数 |
| 2 | 135 | 265 | 3 | 7 | 了解各预测相关算法，对比性能 |
| 3 | 20 | 285 | 1.5 | 8.5 | 验证合理性和稳定性 |
写在后面
感想
032004113:
第二次了，虽然和底下那个✨天天抬头不见低头见，但做起事情来，
也就彼此彼此。（卑微求饶）毕竟平时谁不是自己干自己的呢。所幸，有过上一次的结对之后，对彼此的能力和习惯已经有了一定的了解，两人相互配合完成的也是挺不错的。
对我自己嘛，这一次自己手写了数据集生成的代码，虽然没太大难度，但是成就感还是蛮大的。其次就是GitHub的使用，本来就不是很清楚，再这么久（也就半个月）没用一下，就用的乱七八糟了，还好有✨，不然这个代码仓库可能就见不到了。
032004122：
这次是和楼上的👑同学第二次合作了，这次的合作沟通交流也比上次要好很多了，很多时候都能快速理解对方的想法。
毕竟平时交流有问题的时候就跑到他宿舍去给他一拳。同学在理论上给了我许多的帮助，在相关的分析和设计上也有很深的见解，对我能顺利写出相关算法的代码给予不小的助力。由于我们都没有相关开发项目的经验，所以如项目结构、开发规范等方面做的都不尽完善，这也算是一点小小的缺憾。同时也建议楼上的同学可以看看git commit message的相关规范，我俩写的都挺抽象的哈哈哈。希望下次还有机会的话还能多多一起合作（然后一个人单刷带我）。
结对照片
386
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
