歌姬什麼的，不幹了啦！星塵要旅遊！
於是星塵換上了蝴蝶套裝在一片為 \(p\) 層每層n行m列的矩陣中開始了她的旅行，她從 \((1,1,1)\) 出發，到 \((x,y,z)\) 去。這片空間裡有一些是不能通過的，因為這些空間內沒有以太之塵，星塵飛不起來。現在告訴你**有以太之塵，請你依照 \(x\) 軸正 \(（x+1）\) 、\(y\) 軸正 \(（y+1）\)、\(z\) 軸正 \(（z+1）\)、\(x\) 軸負 \(（x-1）\)、\(y\) 軸負 \(（y-1）\)、\(z\) 軸負 \(（z-1）\)的順序找到到達終點的所有路徑，
對於每一條路徑，不能走回頭路，因為走過的路也沒有以太之塵。記住，每條路徑之間不會互相干擾，這一條走過某個位置不影響另一條路徑走過這個位置。如果不能到達輸出 \(-1\)。
輸入格式
第一行六個整數表示 \(p\) 層每層 \(n\) 行 \(m\) 列和終點座標 \(x、y、z\)
接下來有 \(p\) 個矩陣，每個矩陣有 \(n\) 行 \(m\) 列，\(1\) 表示可以通過。
輸出格式
輸出從起點到終點的所有路徑，不存在輸出 \(-1\)
樣例輸入
3 3 3 3 3 1
1 1 1
0 0 1
0 0 1
1 0 0
0 0 0
0 0 1
1 1 1
0 0 1
0 0 1
樣例輸出
(1,1,1)->(1,2,1)->(1,3,1)->(2,3,1)->(3,3,1)
(1,1,1)->(1,1,2)->(1,1,3)->(1,2,3)->(1,3,3)->(2,3,3)->(3,3,3)->(3,3,2)->(3,3,1)
資料範圍
\(n,m,p\le 10\)
lgj出的毒瘤搜尋……但是這個……三維搜尋……有（yi）點複雜啊……
如果要輸出路徑的話就必須用深搜勒~ 但是，「在寫這道題被 \(tle\) 狂虐中我明白了，越是優化剪枝（其實並沒有什麼可剪的）抓耳撓腮，越會發現 \(dfs\) 的力量是有限的，除非超越 \(dfs\)。……所以……我用 \(bfs\) 辣！jojo！[嗶——]」
注意到如果根本無法到達終點的話，\(dfs\) 就會像無頭蒼蠅一樣到處搜尋，時間複雜度大大提高，所以，可以考慮先用 \(bfs\) 搜尋一遍判斷是否可以到達終點，如果不能直接輸出 \(-1\) 結束程式，這樣便使得 \(dfs\) 不會因為無法到達終點而時間超限。
確定演算法之後就來到了這道題最另人頭禿的地方了：確定 \(x、y、z\) 軸。
將樣例畫出來之後如下圖所示：
（黑色、藍色、紅色分別為不同的層）
題目中的兩條路徑分別為：
所以，題目中的座標 \((x,y,z)\) 指的是第 \(x\) 層 \(y\) 行 \(z\) 列的點，在搜尋或輸入時一定要注意！
#include using namespace std;
int a[11][11][11],v[11][11][11];
struct noded[1010];//bfs的佇列
int dx[6]=,dy[6]=,dz[6]=;//座標移動陣列
int px[1010],py[1010],pz[1010];//輸出(put_out)陣列
int m,n,p,zx,zy,zz;
bool bfs()//判斷是否能夠到達終點
}head++;
}return false;
}void put_out(int x)
void dfs(int x,int y,int z,int cnt)
for(int i=0;i<6;i++)
}}int main()
px[0]=py[0]=pz[0]=1;
a[1][1][1]=0;
dfs(1,1,1,0);
return 0;
}
lgj nb!!!（破音）
最後，完結撒fa~
動態規劃 採藥問題 原題 題解
這裡的採藥問題是乙個典型的0 1揹包。原題 引用open judge 總時間限制 1000ms 記憶體限制 65536kb 描述辰辰是個很有潛能 天資聰穎的孩子，他的夢想是稱為世界上最偉大的醫師。為此，他想拜附近最有威望的醫師為師。醫師為了判斷他的資質，給他出了乙個難題。醫師把他帶到個到處都是草藥的...
原環套原環
今天在除錯兄弟的程式的時候發現了乙個問題，就是在組合資料的時候，有些時候可以成功，有些時候失敗，感覺十分奇怪。功能大概是這樣的，就是在一棵樹上掛資料，所有的節點都可以有資料，不只是葉子的，在組合資料的時候，可以從任意節點取資料，但是不能是重複的資料。資料可能出現的情況如圖a b c所示，圖a是沒有干...
MongoDB writeConcern原理解析
mongodb支援客戶端靈活配置寫入策略 writeconcern 以滿足不同場景的需求。db.collection.insert mongodb支援的writeconncern選項如下 w 資料寫入到number個節點才向用客戶端確認 j 寫入操作的journal持久化後才向客戶端確認 wtime...