• 黄金点游戏总结博客


    黄金点游戏作业要求:

    作业要求

    项目源码的github地址:

    源码

    2. 不适用,因为这个项目我们的实现比较简单,我们本身并没有用PSP记录时间。

    3. 设计了Data类用于formalize获取到的队伍数据,用Policy类包含所有用到的方法。用getNumbers作为输入接口调用这两个模块。在结对编程中,其中在

    4. 代码中有两个类

    • Data类,从输入流中读取数据,对输入数据进行预处理,提取出一些属性信息比如队伍数,轮数,和每一轮的黄金点等等。将这些信息打包在黄金点历史和队伍历史中传递给policy类
    • Policy类,用Data类传递的数据进行初始化,其中包含几种常见算法,比如算数平均,滑动平均和指数滑动平均,以及波动程度检测和随机波动生成等方法。
    • 算法的关键在于,检测当前的波动程度,一般用前五次黄金点的波动极差,方差和标准差来衡量,具体设置的threshhold根据作图经验性的设定。比如对前400轮数据进行作图,观测到对于波动范围不大的情况下,一般极差不超过3,方差不超过2.5,在这种情况下,我们采取的是对短期建模较为准确的滑动平均,并且输出的两个值分别是滑动平均和指数滑动平均。如果我们检测到最近黄金点的波动比较平稳,这个时候我们进行随机数扰动就有利可图并且也易于预测。这个时候我们就会输出仅考虑了自己输出随机数以后的滑动平均。如果波动比较剧烈,这个时候输出随机数反倒容易扣分,所以就老老实实地一个输出滑动平均,一个输出对长期建模比较准确的指数滑动平均。

     5. 各个类之间的结构就是类似pipeline的结构,由Data类处理过的输入输出到Policy类中,由算法处理后输出要输出的两个数字。

     6. Code Contract的有点在于能够生成语言无关的检测,通过定义前置条件,后置条件和不变量来对一些关系进行约束。避免一些没有意义的参数测试,来生成有意义的单元测试。由于Code Contract执行的是编译前检查,所以能够提高编译效率。但是缺点在于,代码契约有可能对代码造成不必要的约束。在我们的结对编程中,由于我们的代码比较简短,我们也并没有使用Code Contract。

    7. 我们约定的代码规范是要求对于函数的域必须是私有的,被隐藏的。程序中没有异常捕捉,因为我们的程序在逻辑上保证了数字不会越界产生未预料的输出。虽然加一些assert语句是有益的。

    8. 我们的程序没有界面,因为程序是在服务器上被调用,输入输出通过命令行。

    9. 理由同上,本条不适用。

    10. 结对的过程中,我们的合作方式是先一起协商策略,林郅琦负责编码和测试工作,我负责代码复审。在第一轮的比赛结束后代码调整的半个小时里,我负责对前400 rounds数据的统计分析,策略调整和阈值估计,林郅琦对代码进行相应修改。

    讨论时照片:

    11. 我们采取的结对编程是我做领航员,林郅琦做驾驶员。我进行复审和代码逻辑修改的意见,林郅琦负责代码的编码和测试。结对编程的优点,其中一方对代码比较熟悉,能够非常熟练地对代码做出修改,另一方可以进行分析和意见的提出,能够对编码的思路提出建议。缺点在于,在编码速度上不如两人同时编码。

    林郅琦的优点:

    • 动手能力强
    • 对python库比较熟悉,能够迅速找到需要使用的函数
    • 对时间序列预测的算法有了解

    他的缺点:

    • 对数据统计和分析没有重视

    我的优点:

    • 能根据实际情况想出相应的对策
    • 根据前400轮的统计数据和实时波动情况进行统计量分析和策略调整
    • 对他人的代码逻辑和数据结构能够理解和掌握,便于之后的修改

    我的缺点:

    • 没有对自己的新想法和新模型进行编码和优化

    如果采用三明治方法,我会首先说:

    你这段代码写的非常规范,并且逻辑也很清晰严密。

    但是如果能根据比赛的实际情况进行一下调整就更好了。比如分析出前3~5轮黄金点的极差,方差或者标准差的带下进行不同的策略调整,或者对其他选手所采用的策略进行大致预估。

     你这几个算法写的还是挺有效的,但是如果能将这几个算法根据比赛的实际情况进行有机结合,效果会更加出色!

    12. 理由同上,我们并没有用PSP表格记录我们结对编程的时间

    13. 其他收获:这次比赛的结果比较的遗憾。在前400轮的比赛中,我们稳稳地拿到了最后一名,后来对我们的输出情况和黄金点的波动情况进行了分析,发现由于总共有6支队伍都在比赛的过程中输出了随机数,而我们的程序在预测的时候只考虑了自己的随机数,这就使得我们的预测结果每一轮都比实际的黄金点结果要高,并且在这种情况下指数滑动平均完全失去了预测功能。后来我们调整了策略采取对短期建模比较好的滑动平均并随机应变,在第二轮取得了第三名,最后总分倒数第三名,非常遗憾。在比赛的过程中,我们理解了并不一定要一一种方式解决问题,能够随机应变的策略才是好策略。同时也对其他队伍的算法非常的佩服,因为他们的算法非常的鲁棒,既能够在强烈的干扰下做出相对准确的预测,又能在平稳的情况下进行更加精准的预测。

  • 相关阅读:
    Lodop实现web套打
    oracle监听文件 内容
    【数据存储】【Redis】第四章:高并发下实现分布式锁
    Demo:第二章:Java实现随机图像生成(人像,汽车,房屋等等)
    【数据存储】【Redis】第五章:Redis缓存String类型的使用场景
    【数据存储】【Redis】第三章: Redis五大数据类型实现原理
    【Java面试】:第三章:P6级面试
    【数据存储】【Redis】第二章:底层数据结构
    实战:第二十二章:i18n国际化(已实现中文,英文,波兰文)
    Demo:第三章:权限框架spring security oauth2
  • 原文地址:https://www.cnblogs.com/xyyimian/p/9821763.html
Copyright © 2020-2023  润新知