- 主题:数字华容道程序速度快速下降，比C#慢几十倍
快过c#没？
【 在 finlab 的大作中提到: 】
: 找到问题了，我的hash算法不好，换了个公式就快了
:
--
FROM 1.85.201.*
别扯淡了，科学家。
构造函数好好写写，也能更少好多行。
还memcpy，让人注意力全在内存上了。
类型上把operator==重载，也能提高阅读性
若要对象快，加一个Node对象池。
还有在move函数上，注释move，就像网图，禁行标牌，旁边再立个小标牌：“这是禁行”。
【 在 finlab 的大作中提到: 】
: 这是正宗的启发式搜索算法，熟悉的人一眼就明白，不熟悉的话几句话也说不明白。
:
: 如果按照标准库的风格，容器里直接放对象，不用指针，避免了大量零碎的对象内存分配，但是容器本身占用的存储会大很多，容器内存维护的负担会加重。
: ...................
--
FROM 117.39.234.*
大眼一扫，优先队列，上次见是opecv里分水岭算法。
算法mental model是根据灰度值，将图像素三维化，假设有高度，然后注水。
低的地方汇聚成洼，高的地方分割成坝，达到分割的效果。
除了优先队列，还有hist（gram），也比较像，灰度直方图，统计同一灰度值的个数。
move是移动规则，决定水往哪里流，大坝哪里走，寻找下一个注水点。
另外第一个注水点选的太好，直接分割完把自己封闭在边界角落了，就要全局干预一下，查找未访问的像素。
我不没听过启发式搜索，但就这么几行，它绝不会比分割复杂多少。
比深度优先麻烦一点，就是windows画图板填充色块的算法^_^，
种子法搜索连通域，升级下的效果。
总之科学家写代码就这样，总觉得自己在弄高尚纯洁的东西，软件工程会损害自己。
【 在 here080 的大作中提到: 】
: 别跟我谈算法，你直接说你这个数字华容道出来是个什么效果。
:
--
FROM 1.85.200.*
这一看就是忽悠小年轻干活的好领导，你是不是升职了？:-D
【 在 javaboy 的大作中提到: 】
: 他那个代码其实我之前粗看了一下，也怀疑是hash或者是queue的问题，不过被别的事情打岔了就没回复，后来他自己试出来了。
: 他这个代码写得也不算太难看，应该算是比较懂C++的了。至于算法干嘛的，估计人家那是业务机密，算了别问到底了吧。
:
--
FROM 1.85.200.*
哈哈，很有爱，给你点赞。一说女儿，画风就变了，
从科学家化身超级英雄啦～
什么程序不程序的，没那么重要
【 在 finlab 的大作中提到: 】
: 这段程序是求解数字华容道。 就是在N*N的矩阵里，随意放入数字1到N*N-1，留1个空格，然后利用空格移动数字，使的数字按顺序排列。
: 因为闺女这几天老玩这个，非常溜，1分钟就能完成， 我就想给闺女露一手，编程求解出更快的走法。
: 一开始的C++程序慢，使因为未unordered_set提供的hash函数太差，改成 hash=hash*13+A[i]之后，C++就比C#更快了。
: ...................
--
FROM 117.39.234.*
是的，如果是工作，拿钱干活还行。
论坛交流，没有耐心看。一般讨论，想深入讨论，这样贴代码确实太粗糙了。
他说的倒也没毛病，懂的自然懂。这就是交流的典型醉汉困境，各说各的，
我没醉你醉了。——我才没醉你醉了！
【 在 here080 的大作中提到: 】
: 我不太乐意特别细地去看他的代码，因为据我多年code review的经验，特别难读的未提交代码，你各脑补把代码读清楚了，最后多半会发现代码本身就有问题，你脑补出来的不是作者想要达到的效果。读代码首先要弄清作者想要干嘛，然后才不会浪费时间去分析。
:
--
FROM 117.39.234.*