暑假一道图论题，本来写着A，B两题的dfs和bfs，本着不浪费（刚写的dfs和bfs的AC代码）的原则，就直接想写代码
主要是因为
↓↓↓↓↓↓↓↓↓↓
正常电脑一秒5e7
可……
也就是O((64)³)都可以跑出光速（故意的，因为打不出4次方）
好了，此篇完结
不是哥们，你倒是写个O((64)³)的代码呀
没错，写不出来
别急，先看这个—> 哈密尔顿路径
如果你写正常代码………………
千奇百怪の死法
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
死亡回放1
暴搜，直接考虑每一个点的到达顺序，因为第i个点有（64-i+1）种可能，所以直接O(64!)，还要考虑检查结果是否合理，这个的方法很多，但……
— ↓↓ —
总结
三体人来算，算完地球人都亖完了
死亡回放2
众所周知的dfs，对于每个点，都有8种可能性，所以n = 64,时间复杂度O(8ⁿ)，但有些点可能在前面走过所以最终的时间复杂度会略微小一点
— ↓↓ —
总结
你让 神威·太湖之光 来，都得吃不了兜着走
到底怎么写！！！！！！
这道题就是一个哈密瓜炖路径
动用一下人类智慧，考虑对于仅需一个正解就行的题目，有很多不必要的计算是冗余的
记得优先队列优化最短路吗？和它没关系。
其实用一个启发式优化 就可以了
给一下AC代码碎片
for (int i = 0; i < 8; i++)
{
int nx = x + dx[i],ny = y + dy[i];
if (mc(nx, ny)) //move_check,检查是否可以移动
{
next.push_back({count(nx, ny), i});
}
}
// 按可选移动数升序排序（启发式优化）
sort(next.begin(), next.end());
for (auto& p : next)
{
int i = p.s;
int nx = x + dx[i], ny = y + dy[i];
if (solve(nx, ny, move + 1)) //动一动
return true;
}//next是个vector
其实说白了就是给机会少的点传递（其实我也不知道优化了哪里，就跟线段树的懒标记一样，其实最坏跟没写是差不多的）
实战
不过既然写了题，就写篇帖子记录一下，下次就不用再……
花2小时调代码，2小时找正解了
有兴趣的童鞋可以看看这道题
