tsp的理论和实践(10)tsp系列暂停一下

目前tsp系列已经写了9篇了, 没有哪一篇的阅读量超过100, 对比一下, 随便写的[面试]和[简历]这两篇, 6分钟阅读量就200了. 最关键的是: 一个留言都没有.

那么, 暂停一下并不是单纯的因为反响不热烈, 也因为我对LK的初步的研究结果:

1. LK实际上用了翻煎饼的策略, 也就是说一摞煎饼一起翻, 这样是为了每次做交换的时候, 避免太多的副作用影响.
2. 但是这个策略在快递的实际应用中有严重的问题. 我们之前分析过, 快递业是有取派件依赖的.
3. 翻煎饼导致, 我们要加入路线是否合理的校验, 然后这个校验非常容易不成立, 导致算法无法链式执行下去.
4. 这样有两个结果:
   1. 线路探索不充分, 结果的最优性存疑.
   2. 因为校验判断内容增加了每个点的依赖合理判断, 延误的计算的效率.
5. 但是也是有好处的, 因为这个校验会大幅度缩减链式的深度, 所以, 可能会导致算法速度提升.

至此, 我可以做两件事:

1. 实现一个针对快递业的LK算法, 校验一下上面的优点成立还是缺点暴露.
2. 深度思考这个算法, 找到扬长避短的一个定制的LK算法.

这两件事不论做哪一件, 都需要我思考一段时间, 并且很认真的实现这个算法. 但是, 我本身对于编辑器领域的兴趣更大, 那个领域我已经研究了3年了, 之前卡在了一个技术节点上, 目前应该会突破. 所以, 我后面相当长的一段时间会投入到编辑器领域. 这些内容也会形成分享文章, 还是一句老话, 期待大家的交流和沟通.

最后, 顺便推一个js框架方案: stampit, 这个框架之前有一个严重的问题: getter/setter不支持. 不过我(lornally)最新的pr已经解决了这个问题, 我们目前合并这个pr的困难在于, 这个pr比较大, 会影响specification. 所以, 我们现在在specification那边讨论是否修改spe:) 相信很快就有结果了. 来吧, 一起体会下没有class的纯prototype+functional之美.

转载于:https://juejin.im/post/5d302e6f6fb9a07ed1370bef