OO的奇妙冒险——OOP入门与字符串处理

OO的奇妙冒险 _{OOP入门与字符串处理}

总体分析

公测

• 中测(基础与进阶):
  • 其实在我看来，从完成作业的角度来说，中测的基础与进阶并没有任何区别，都不能挂，都不太难，都对得分没有什么影响。中测的样例总体来说非常善良，只要是测试过，几乎不会被中测阻拦。checkstyle的规则看似很多，但是在IDEA插件的支持下，见到黄色的warning直接改掉，总体来说我认为偏向于养成习惯性的举措，并不是扣分地方所在
• 强测(正确性):
  • 在第一次作业之前，我十分畏惧强测的正确性，尤其是在经历了计组手动定点爆破+10万条随机都仅是中测的说法，但是，就前三次来看，强测的正确性并不严格。第一次作业比较简单，第二次作业我正则表达式根本就没有写对，面对这个十分巨大的问题，强测仅仅挂了我三组，我在发出强测不够强的想法的同时也暗自窃喜，而第三次作业的重点向面向对象转移 ，对于正确性的检查更加简单，在我连爆sin(- 9),sin(++1),sin(+++1),sin(++x)4个大型bug的情况下强测一组也没挂，互测又禁掉了WF的攻击，不得不说我并不完全认同的强测数据反而救了我一命
• 强测(性能)：
  • 第一次作业比较简单，第二次作业我进行了初步的贪心优化，然而偷鸡不成蚀把米，优化也出现了bug，我对第二次作业非常满意，但是对自己做出的结果非常不满意。第三次作业由于以下几个原因，我放弃了优化转战OS
    • 自己能力太差
    • 长度最短的L记为Lmin，就意味着1位dalao可以灭杀所有的人，dalao之下丝毫不优化和熬夜爆肝优化是同等的，我并没有直接挑战的信心和能力
    • 性能分仅占5分
    • OS等其他课程需要投入时间

互测：

• 第一次互测可以说是相当惨烈。在一个强测全部100分的房间内，8个人总计被找出了50个bug，4人无伤，3人轻伤，1人重伤，我认为原因有下：
  • 第一次接触大规模测试，发生了v惨案，爆栈惨案等bug
  • 强测不够强，将一部分性能bug放了过去(例如x-x输出为空而不是0)
  • 规则尚未完善，被hack1/x等价于被hack7/x
• 第二次互测由于作业做得很差，进入了C屋，战况同样十分惨烈。在C屋使用对拍器甚至评测机进行测试效果是非常显著地，一屋7个人人人有bug，基本就是大礼包互开的级别，我被查出了正则的巨型bug，不过考虑到客观因素(C屋里对拍器并不普及)，仅被人hack3次，如果身处第一次互测的房间，应该是20次起步吧
• 第三次互测由于无法提交WF变得十分无聊，一个屋子的95.8824大眼瞪小眼，不优化的人bug反而更不容易出现，战绩0/0,0/9，不过屋里还是有人因为做了简单的优化而被人查出了bug，这次互测给我的教育是，制造SPJ时要考虑周全，先要判断这个输出是不是WF，再调用sympy进行验证，因为sympy识别的表达式并不一定满足作业要求的文法

作业内容分析

• 第一次作业比较简单

• 第二次作业正确性不太困难，但由于个人因素对正则表达式理解不深，检查不细，出现了十分荒谬的bug。优化方面，总体可以分为

  • 纯第一次的策略
  • 贪心合并
  • 贪心合并+分拆
  • 深搜+剪枝
  • 我看不懂的算法

  这几个层次。我采用的是贪心合并的层次，但由于是周二晚上心血来潮才开始优化，处理的很差，出现bug几乎是必然结果，也算作一个惨痛的教训

• 第三次作业比较特殊，具体体现在

  • 面向过程+递归下降+简单的强测+没有WF的互测=轻松地95.8824
  • 性能分计算方法+只有5分=不做优化去学习OS可能是更好的选择

  在这些因素的考虑下，我选择了权衡所有的科目，进而去学习OS，从而放弃了优化任务。总的来说这次作业正确性的方法比较唯二，arraylist或树，而结合递归下降的方法，封装三种数据结构+Get类递归下降+Main类入口+预处理检查是一个简易可行的方案。面对助教所讲授的面向对象递归下降分析，我认为考虑可能的扩展性，这种封装其实并没有特别大的意义，直接在Get类里面设置Char[] origin与int mark,构造Getconst，GetF，GetT，GetE这四个方法肯能会更直接，更好实现。至于扩展方面，如果更换文法，直接继承了重写具体的某一个Getx方法即可

  不过总的来说，我对第三次作业“trade-off”的结果比较满意，但对于作业的完成情况并不满意。本应是第一单元的收官之作，却在客观层面和各种时间投入策略的权衡上上变成了第一单元最简单的一次作业，对于个人来说有关OOP的收获并不如第二次上机或第二次作业的大(不过巩固了陌生的递归下降分析方法)

作业内容总结

互测的收获

• 首先，互测最大的收获是提高了自己对评测机的认识
  • 第一次接触评测机是在计组，在计组进入P5之后，手动测试就完全没有功效了，自动测试的需求应然而生。到了实现P7的时候，我完成了一个十分简陋的对拍器，仅仅是检查字符串，总共就是一个100行左右的C程序
  • 为了应付第一次作业，我做出了一个“感知机”，顾名思义，就是只检查双方对于是不是WF的判断是否一致。到第三次作业，终于用python写出了一个差不多的判断程序。数据生成方面，从最开始的完全随机字符串(没有卵用),到马尔科夫矩阵生成的表达式，再到用Xeger生成+随机引入噪声，再到现在的Xeger部件+随机选取，我不仅了解到了很多“轮子”的使用方法，更明白了随机性的重要性
• 其次，是发现别人bug的同时，看到别人的代码
  • 发现别人的bug比较简单，挂上评测机跑几个小时，有就有，没有就算，在评测机的帮助下，几乎不用过多的检查代码。不过，对于使用大型正则表达式的代码，直接对着正则表达式分析也是很有帮助的
  • 第一次作业偶然查看同组Lancer的代码让我获益匪浅，因此第二三次中，我都会查看一下优化效果不错的，评测机扫不出来的dalao的代码，可以学习别人的思路，尤其是第二次作业公开展示的HDLdalao的代码，虽然并不能完全看懂，但总体模板还是很有启发性的