鐵人檔案
當 AI 已經會寫程式，我們更需要知道問題為什麼要這樣解。
這個系列不以「背演算法」或「刷 LeetCode」為目標。
是想輕鬆的從生活問題出發，建立起：
描述問題 → 尋找答案 → 面對變化 → 做出選擇 → 接受取捨
這樣思考的過程。
很多人都說 AI 這麼厲害，幹嘛還學演算法？
但看完這次的系列文章，你應該可以理解：
AI 不能幫我們解決的是藏在 DSA 後面的那些權衡和取捨
上一篇談到 DFS 時，我們做了一個很明確的選擇： 先沿著一條路一路走到底 這是一種搜尋策略。但如果今天問題換方向了呢？ 假設我們面前不是迷宮，而是一張捷運...
前兩篇，我們分別看過了兩種很常見的 Graph 搜尋方式： Graph + Stack → DFS Graph + Queue → BFS DFS 選擇先沿著...
上一篇我們討論 BFS 時，用了一個很適合它的問題： 從 A 到 F，最少要經過幾個站？ 只要每經過一個站，都把它看成相同的一步，BFS 就能一層一層往外搜...
前幾天我們一直用 Graph 描述「東西之間怎麼連在一起」。例如捷運路網： 我們在意的是： 從 A 能不能走到 F？哪條路比較短？哪條路花的時間比較少？ 但...
上一篇我們開始把「事情必須按照先後順序完成」畫成有向圖。例如： 買食材 → 備料 → 烹煮 → 上桌 箭頭代表 dependency： A → B 可以理解...
上一篇我們看到，Dependency Graph 最麻煩的情況之一，就是出現循環。例如： A → B → C → A 如果箭頭代表： 前面的工作必須先完成，...
前幾篇，我們已經從「事情的先後順序」一路談到有向圖、Cycle、DAG 與拓樸排序。例如： A → B → C 代表： B 依賴 A，C 又依賴 B 這種...
上一篇，我們把 npm 專案看成了一張 Dependency Graph。當一個 package 依賴另一個 package 時，我們可以把關係畫成 A → B...
上一篇，我們談到 dependency 不只可以描述： 誰必須先完成？ 也可以幫助我們回答： 當某個東西改變時，哪些地方可能需要跟著重新計算？ 例如：...
前幾篇，我們一路從 dependency、propagation 談到 Graph 本身也可能隨著系統執行而改變。到這裡，我們已經不只是在描述資料結構，也開始面...
