tsp目录面试
- 最简单的实践 juejin.im/post/5d1b14…
- 最简单的理论 juejin.im/post/5d1b15…
- 当前tsp的现状 juejin.im/post/5d1b19…
- 单起点任务分配 juejin.im/post/5d1c6d…
- 多起点任务分配 juejin.im/post/5d1dbe…
- 更简洁的多起点分配 juejin.im/post/5d1dc2…
- 起点时间窗 juejin.im/post/5d1f1f…
- 终点时间窗和hk juejin.im/post/5d1f44…
- LK简介 juejin.im/post/5d25b8…
- tsp系列暂停一下 juejin.im/post/5d302e…
目前tsp系列已经写了9篇了, 没有哪一篇的阅读量超过100, 对比一下, 随便写的[面试]和[简历]这两篇, 6分钟阅读量就200了. 最关键的是: 一个留言都没有.算法
那么, 暂停一下并非单纯的由于反响不热烈, 也由于我对LK的初步的研究结果:框架
- LK实际上用了翻煎饼的策略, 也就是说一摞煎饼一块儿翻, 这样是为了每次作交换的时候, 避免太多的反作用影响.
- 可是这个策略在快递的实际应用中有严重的问题. 咱们以前分析过, 快递业是有取派件依赖的.
- 翻煎饼致使, 咱们要加入路线是否合理的校验, 而后这个校验很是容易不成立, 致使算法没法链式执行下去.
- 这样有两个结果:
- 线路探索不充分, 结果的最优性存疑.
- 由于校验判断内容增长了每一个点的依赖合理判断, 延误的计算的效率.
- 可是也是有好处的, 由于这个校验会大幅度缩减链式的深度, 因此, 可能会致使算法速度提高.
至此, 我能够作两件事:编辑器
- 实现一个针对快递业的LK算法, 校验一下上面的优势成立仍是缺点暴露.
- 深度思考这个算法, 找到扬长避短的一个定制的LK算法.
这两件事不论作哪一件, 都须要我思考一段时间, 而且很认真的实现这个算法. 可是, 我自己对于编辑器领域的兴趣更大, 那个领域我已经研究了3年了, 以前卡在了一个技术节点上, 目前应该会突破. 因此, 我后面至关长的一段时间会投入到编辑器领域. 这些内容也会造成分享文章, 仍是一句老话, 期待你们的交流和沟通.post
最后, 顺便推一个js框架方案: stampit, 这个框架以前有一个严重的问题: getter/setter不支持. 不过我(lornally)最新的pr已经解决了这个问题, 咱们目前合并这个pr的困难在于, 这个pr比较大, 会影响specification. 因此, 咱们如今在specification那边讨论是否修改spe:) 相信很快就有结果了. 来吧, 一块儿体会下没有class的纯prototype+functional之美.prototype