|
本来想发状态的，结果越写越多，就成了篇日志。 看论文时要想想问题的本质是什么？这个解法是要解决什么问题，这个方法利用了什么样的数据中什么样的隐藏的性质结构或者现实中的什么现象，为了解决这个问题需要应对什么挑战，这些挑战中那些问题是必定会出现的，那些是与数据集或者环境相关的，先想清楚这些问题，再进入下一层细节的考虑，思考对数据的变换是为了完成更细层次上的什么样的子目的，是怎样完成这一任务的，完成任务的步骤是否与问题本身强相关或是仅仅因同时出现才在一起表述，是否有其他的解决办法，新办法会否产生新问题或带来不同指标间的tradeoff 如何认清楚本质，才能不会想当然，可是认识本质的过程中最容易范的错误就是想当然然后想骗了歧路亡羊，这就是个迭代的过程，你看的相关的主题多了，就不会在看的过程中想当然，做出些无根据的假设。同样的，你思考的深入了，也不会在阅读时问些肤浅的你已知道答案的问题，而这时你就更能提出具体情境下关乎本质的问题，所以理解问题不是一蹴而就的，理解才是分析改进的基础。这是我看源代码的体悟，很自然可以应用到看论文上。但对于改善夫妻子女间的关系，应该也是类似的道理。交流无外乎对数据的处理和表达。 处理数据，交流时要分清表达的内容的形式的分别，有些在相近地方表达的东西不一定在内容上强相关，论文在写作时会试图针对数据讲一个合情合理的故事，代码时会为了性能的优化而遮盖主要的处理流程，交流时人会为了面子或者其他的动机有所掩盖。找到重点要注意重复出现的类似的模式，而不是故事上貌似合理的逻辑，看清楚本质，才能不陷入先入为主的经验主义的错误。 不要为了rule去找例子，而是根据要研究事物的本来现象去寻找pattern，看看pattern和instance是怎么关联起来的，这样的关联是一对一还是一堆对多还是多对多，是否有不满足这一pattern的特例，有多少，都是什么类别的，这些特例的影响是否会cascade，再根据这些pattern去找出尽可能多的rule去涵盖并处理这些pattern。 这一步就如同考古学家发掘古迹侦探查案，大胆假设小心验证，而不是一开始就通过建模简化问题，建模时也要明白模型深化复杂的历史，明白每一模块都是在那解决什么问题的，最后再将由这些pattern得到的rule按一定的顺序组合连接迭代，这就形成了算法。只有这样得到的算法才算是启发式算法，否则你瞎想的东西，无法算的上创新。启发式这三个字，实在是解决一切复杂问题的关键，不设定法，方能根据不同的初始数据集选择不同的参数，制定不同的启发式策略。这一点正应和了孔子的“因材施教”。 其实好多说交流技巧的书，讲的也是要捉住对话中的本质问题，不要迷失在枝节，要有层级，要分主次，要回应对方的深层次的pattern而非提出的看似是解法实际为症结的方案。这些和之前提到的看论文时要思考的问题也是类似的，但并非你一方面好了另一方面也好，你可能陷入了只适合一个小领域的经验里，把所有遇到的问题试图用同样的问题去解决，这就有些像陷入了局部最优，需要一个外在的推动力使你接着去寻找更好的办法，而新的领域无疑是带来新见解新思路最好的土壤。 遇到新领域时，不要以为大道相通。一通皆通，嘻嘻，这是大牛爬上顶峰后一览众山小语境下说的。我都说了，对问题本质的理解，不管是哪一个方面的问题，都是一个迭代的过程，是需要花很多工夫的。只是你懂了大道相通的道理，你可以用更广泛的数据进行迭代，更快的理解到本质。这就像练内功，一般人只是白天练，如果你能触类旁通四处借鉴，能对自己深入浅出的讲解不同领域的领悟，就是白天夜里都在修炼内功，这样修炼更加有趣，进展也快些，但并不意味着你不需要下苦功夫。理解迭代的本质，理解每一步变化了什么，为什么要这样变化，这样的变化会带来多少假阳性或者假阴性的判断（错过缘分，抓住孽缘）就能理解启发式的算法，也能理解启发式的人生选择。我们不需要看过世界，就能有世界观，世界观的产生与看世界，本就是个迭代的过程，只是这个过程怕是人类生存多久，就要纠结人类多久了。 |
|
|
