没有想到时间会不够用！这是来到这里的真实感受，每天不停歇地看电脑，资料，刷题！几乎没有停下过，有点喘不过气来，不过身体却有一种莫名的兴奋！

    不喜欢拖拉的人，可自己又总是这样！某种程度上讲，这也是种偷懒吧！看到老师的总结的通知，心里却想着调完这道题再写，结果一直到走还没有调出来！然后只得回到宿舍加班补写，小小屏幕实在费劲，早知如此就不当初了！

    实在惭愧的一件事，给定的3个小时内竟然没有把题读完，其实这是想要拿金甚至夺冠的致命伤！要想拿好的成绩迟早有天要放弃在跟榜的题目上浪费大量时间的恶习，要想优秀你总得会点别人不会的！在去华理的时候，犯了同样的错误，没有读完题，当时杠在一道题的时间上太长，而且队友配合不是很好，最后题都没读完，更不要提想出每个题的算法了！那个时候就已经察觉到这个缺点，当时想想就算读完该不会的还是不会，倒不如花时间去调试，这竟然成了安慰！归根到底是算法思维不成熟，而现在不一样，如果一直这样下去将一直跟在别人屁股后面！

     说说题的情况吧！看第一道题的时候看了下板，ok，没人ac,尽管开始看的时候比赛已经过了10分钟左右，当时还心想要拿下1y，果断快速读题，其实是有一点兴奋的，倒读的，一种坏习惯，比赛的时候有时候先看样例然后意淫答案，读不懂或者解法很复杂就按意淫的算法！倒读了输入输出，其实这个时候我关注的是数据量，输入输出格式，然后要求的数据是什么，根据样例大概猜出个题意然后在去读正题，第一题读到摘到最大苹果时，心里其实在怀疑动态规划，这时有点想打退堂鼓了，不过还是硬着头皮读了下去，什么，从左走摘一个苹果，然后反向走再摘一个苹果，知道一边为空，读了两遍，竟发现题目如此之水，第一个意识使用结构体，然后sort一下位置完事，然后想更好的算法，因为需要排序，自然想到map,set,又因为只有位置和苹果数量，用map做位置和苹果数的映射刚刚好！正负怎办，很快想到用两个map分别存正负，输入的时候顺便计算出在正负方向上的所有苹果的总数，到时候加的时候ans初始化为容器小的那个方向的总苹果数，然后加容器大的那个方向的和小容器size一样的苹果数，最后看两个容器是否一样大，不一样大就多加大容器的一个数据。思路完全没问题，敲之，TLE on test 1，也是醉掉了，看到已经有人过两题，心慌了，此时已差不多一个小时，其实能1a,后来知道这个错误，差点没气死，当然这都是后话了。TLE的第一反应是map不够快，换c++，g++两个都T了，于是改算法，改成了结构体，敲了大概半个小时，心想这不能再T了吧，交之，仍在test 1超时，前前后后交了5-6次，这才意识到原来超时是因为第一句while cin>>n;试着改成scanf，毙了狗了，竟然过了，把第一次的代码照同样方法改，又过，心里暗骂不快。

题目补充：A题摘苹果（第二天补写）

    此时时间已经差不多过大半，士气走些低落，开始读B，其实想a的改进算法时已经在读B，读了两三次，硬是没理解题意和要干什么，抓耳挠腮，和p商量一下，才懂题意，定义数组的美丽为数组中出现数的次数的最大值，然后找出最短子串和原串美丽相同。输出子串上下标。首先想到找出出现最多的数，然后前后遍历，找到上下标即可。敲之，交了一次，wa，又仔细读题发现漏了最短的条件，此时已经两个小时，这个倒觉得做几个算几个把，竟轻松了下来。继续改，也不知道有多久，有人去吃饭了，才意识到时间已经差不多了。中间因为大小于错写又雪上加霜耗了20多分钟。最后收题吃饭已经快六点了，想来自己真是笨！

吃完饭回来看了B的题解，使用俩个数记录数组内所有数的左右位置。然后找出最大的次数，遍历数组找到最大次数的那个数，比较左右区间找出最小即可。这种方法开始的时候是有萌芽的，却没有深想，最终夭折。后面看了CDE的题解，有个扫描线，有个线段树，然而已经没有心情去研究了！

题目补充：B题求美丽子串

    虽然这次很惨，但只是起点，没什么！哪怕下面更惨，重要的是学到了东西！

AcBoy

2015.7.22凌晨