大三小学弟,这学期课业压力比较小,本来报名了网络技术大赛,搜东西的时候看到了这个,然后就顺便参加了,貌似四月上旬就已经报名了,但是一直在想算法,然后看着排名上的分各种高,离比赛还有一周多的时候开始做。
搞懂cmake+mac的压缩方式会导致编译失败问题的解决用了一天,两天把算法编了个大概。
预测方面开始采用了指数平滑,但是此时背包问题解决的不是很好,分数在70分以下,所以后来弃用了,看了网上的评论,以及画了一遍提供的数据的整体走势图,决定直接用一次/二次函数拟合。初赛阶段及复赛阶段都采用了一/二次函数拟合方法,由于个人比较懒,拟合函数的求解过程直接用的遗传算法,求最优参数。
背包问题一直采用的是遗传算法的方法,在初赛阶段,遗传算法采用了最简单的架构,所有的心思主要放在了最优函数的设计上。然后二次函数+遗传算法成绩83左右。后来采用强行装满的策略,成绩提高到了86,虽然西北赛区人才济济,但是连着肝了三天,估摸着进复赛应该没问题,随放弃继续调整。比赛用例分数248。
初赛算法用c语言写的,各种函数,看着初赛的代码已经写得自己都看不懂了,随重写一遍,提交,各种bug,时间紧任务重,为了更好地看懂自己的代码,随用c++重写一遍。这里的c和c++的区别主要是后期程序面向对象。用例跑的速度还是比较快的,内存开销也比较小,1000个背包的开销大约在70M左右,分配2000台的时间大概在3-5秒,平均利用率在93%左右(大型虚拟较多时,利用率会减小),听说py的速度比较慢,但是没有用py写,不知道py的运行时间在多少。完成了整体预测和装包后成绩大概在80左右。采用的预测方法存在欠拟合现象,随对其进行调整,成绩在83分左右。看着西北赛区90分的大神,感觉可望不可即。但是还有其他事情要做,随放弃继续调参,最终成绩在85分左右。
针对本道赛题,从看到运行数据开始,已经觉得这数据简直没有规律,本地测试了svm,效果简直没有。本人专业与预测也是有些许相关,但是从历史数据进行预测的实例不多,除非系统已经接近稳定。虽然个人角度采用了一/二次函数拟合,但是感觉用多周期分解会有更好地效果。lstm可能效果也会不错,但是由于用例对参赛选手是不可见的,而且提供的用例可用样本量确实不多(开始几个月那么多0),所以本地测试可能会耗费一些精力。
从个人理解上,感觉这道题确实存在很多的bug,时间的预测和背包的存放存在联动作用。如果预测的数据的最大装包率不大,会引起最终成绩的降低。即预测准了,反而成绩下降。也是因为这个原因,在调整算法的时候可能无法获悉到底是两个部分中的哪个部分引起了变化。因此,可以预见,很多同学应该都采用了预测,装包,填满的方法。从工程上讲,这样的做法会使得这个问题变得不那么有意义,但是从这道题上来讲,这可能是最好的做法。当然,填满势必会影响到预测的结果,想要获得较好的结果,那就应当使装满的策略尽可能的对原数据做最小的改变,装包的结果应该尽可能的优。