文章以括號配對問題為例，說明如何把看似依賴堆疊的演算法改寫成平行運算形式。作者受 Oleg Kiselyov 的 More Fun with Monoids 啟發，先從 MapReduce（將資料先映射再彙整的平行運算模式）與幺半群（monoid，具結合律與單位元的代數結構）談起，討論哪些問題能用這類模式表達，並聚焦在判斷一串只含 `(` 與 `)` 的括號是否平衡。

傳統循序解法會使用堆疊：遇到左括號就推入堆疊，遇到右括號就彈出；若在空堆疊時遇到右括號，或最後堆疊仍非空，就代表括號不平衡。作者以 Haskell（函數式程式語言）示範這個邏輯，並指出這個解法直觀，但本質上是一個逐字處理的流程，不容易直接發揮平行化的效益。

關鍵觀察是，在只有一種括號的情況下，不必真的保存整個堆疊內容，只要追蹤堆疊大小即可：左括號視為 +1，右括號視為 -1。如此一來，可把字串中的每個字元平行轉換成數值，再用平行前綴和（parallel prefix sum，也稱 scan，用來計算每個位置之前的累積值）取得每一步的堆疊高度；若最終總和為 0，且過程中沒有任何前綴和小於 0，就能判定括號平衡。作者並以 Futhark（主打資料平行的函數式程式語言）呈現這種資料平行寫法。

這個方法清楚展示了從堆疊式思考轉向平行資料處理的過程：單一括號類型的平衡檢查可以化為數值累積與歸約，因而適合 GPU 或多核心環境。不過文章也暗示，這只是「判斷是否平衡」的平行化技巧，並不等同於完整的括號配對演算法；若要找出每個括號實際對應的位置，或處理更複雜的括號種類，仍需要更精細的平行堆疊或代數結構設計。提供的 Hacker News 討論內容沒有可摘要的留言文字，因此可整理的重點集中在原文對平行括號檢查的演算法說明。

文章指出，AI（人工智慧）正在迫使數學界重新思考「做數學」的意義。作者以自己攻讀應用數學博士的經驗對照純數學研究：前者的模擬與近似工作如今可能被 AI 大幅加速，但純數學家長年面對抽象難題的掙扎，價值不只是得到答案，而是在漫長推理中形成理解、直覺與美感。Carnegie Mellon University 的 Jeremy Avigad 將這種理解形容為複雜事物突然「合在一起」的成就感，也是數學長久以來的核心動力。

文章回顧電腦輔助數學的歷史，從 1976 年四色定理的電腦證明開始，人類數學家仍主導提出猜想、設計證明策略與檢驗正確性。但近年大型語言模型（LLM, Large Language Model）進步迅速，Google DeepMind 與 OpenAI 的系統已達國際數學奧林匹亞（IMO, International Mathematical Olympiad）金牌水準，DeepMind 的 Aletheia 也產出可發表的博士級研究結果，OpenAI 系統則推翻組合幾何中的重要猜想。另一個關鍵進展是將 LLM 與證明助理（proof assistant，可逐步檢查形式化證明的工具）結合，例如 Isabelle、Lean、Rocq；Math, Inc. 的 Gauss 更協助形式化 Maryna Viazovska 關於 8 維球堆積的 Fields Medal 成果，並自動完成更複雜的 24 維案例。

數學界對這些變化的態度分歧。有人認為只要 AI 能解出千禧年大獎難題等重大問題，人類是否參與並非最重要；也有人堅持數學的目的在於人類理解，AI 證明若無法被人讀懂，頂多只是提示「此命題可證」。Terence Tao 則提出「大數學」（Big Mathematics）的願景：人類與機器大規模協作，把複雜問題切分，讓人類負責創造性方向，AI 處理繁重技術細節；形式化驗證則讓陌生人、業餘研究者，甚至 AI 產出的想法，都能以可檢查的證明取得信任。文章也提醒，若高階 AI 工具掌握在少數能負擔專有模型的機構手中，數學可能變得更菁英化；若學生直接跳到答案，也可能削弱培養直覺與深度思考的過程。

Hacker News 討論主要圍繞「AI 證明是否可信」與「理解是否必要」。許多留言質疑，LLM 可能產生看似合理但含有細微錯誤的證明，因此仍需要高階數學家判斷；也有人指出文章已提到 Lean 這類互動式定理證明器（interactive theorem prover），若 AI 產生的是可編譯的 Lean 證明，邏輯正確性可由系統檢查，真正困難在於確認命題表述、使用的公理與形式化內容是否正是研究者想證明的東西。討論也延伸到 Mathlib（Lean 的主要數學函式庫）：形式化證明不只要能通過檢查，還要有乾淨抽象與可供人類使用的介面，否則 20 萬行難以理解的自動產出證明，未必能融入人類數學知識體系。

留言區的整體情緒偏謹慎：不少人認為 AI 會成為強大的研究助理與搜尋工具，但尚未等同取代數學家的新概念創造；也有人接受「有些有用證明可能超出人類理解」的可能性。另一些人則擔心知識與權力集中，因為最強 LLM 需要龐大資源，未來貧富、學校與機構之間的 AI 使用落差，可能影響數學與其他專業領域的公平競爭。多位留言者也提醒，電腦輔助證明的爭議並非新事，四色定理早已開啟這場辯論；差別在於 AI 讓問題從「電腦能否幫忙驗算」升級為「人類還能否理解、主導並延續數學的精神」。

Decomp Academy 是一個互動式學習網站，主打把 GameCube PowerPC 組合語言反編譯成「byte-matching C」（編譯後與原始二進位逐位元組吻合的 C 程式碼）。使用者在課程中閱讀 asm（組合語言），撰寫 C，網站再用真正的 Metrowerks CodeWarrior GC/2.0 編譯器即時評分；只要任何指令或位元不一致，就不算通過。這種嚴格比對是許多遊戲反編譯專案追求的標準，目標不只是得到功能相近的原始碼，而是重建出能編譯成相同機器碼的 C。

網站標榜可從完全沒讀過暫存器開始，逐步練到能重建 Star Fox Adventures 的真實函式。課程超過 250 堂，涵蓋 PowerPC 暫存器、整數運算、位元操作、控制流程、迴圈、型別寬度、指標與記憶體、struct / union / bitfield、浮點數、ABI（Application Binary Interface，應用程式二進位介面）、全域變數、SDA（Small Data Area，小型資料區）、編譯器最佳化與排程、64 位元整數，以及實際遊戲函式練習。網站也提供 playground，可即時比較目標組合語言與輸出結果，並使用來自 Star Fox Adventures、Pikmin 2、Metroid Prime、Mario Party 4 等開源 GameCube 反編譯專案的函式作為教材。

作者在討論中補充，自己原本沒有反編譯、C 或組合語言經驗，是在參與 Star Fox Adventures 反編譯時發現學習資源稀少，才建立 Decomp Academy。網站前端與課程內容開源，課程以 Markdown 存在 repo 中，方便新增或修改；後端則未開源，使用 Rust 撰寫，部署在 AWS Lambda、DynamoDB 與 API Gateway 上，並把老式 GC/2.0 編譯器放進 Lambda 執行。作者也表示未來可能加入 C++ 課程，並考慮讓完成課程的人直接挑戰尚未 100% 匹配的真實反編譯函式，甚至自動產生 PR 來回饋上游專案。

Hacker News 討論集中在反編譯工作流程、AI 輔助與法律風險。多位留言者提到 decomp.me 等既有工具，作者也說網站 playground 可轉成 decomp.me scratch，前端組合語言差異比對則借用 objdiff 的 WebAssembly 版本。有人指出網站目前只檢查編譯後組合語言是否吻合，因此可能出現「fake match」：用可讀性很差或語意不直觀的 C 寫法拼出同樣機器碼；作者回應會觀察情況，必要時調整課程或加強限制。也有早期使用者回報行動版介面與編譯服務容量問題，作者表示正在修正。

關於 LLM（Large Language Model，大型語言模型），討論呈現務實但保留的態度。作者認為 AI 在反編譯可先做到約 95% 的匹配，但最後幾個百分點通常最困難，像 if/else 與三元運算式這類表面等價寫法，都可能讓輸出組合語言不同，因此仍需要熟悉編譯器習性的人工介入。也有人提醒，把 AI 產出的程式碼混入反編譯專案可能帶來著作權與 fair use（合理使用）爭議；另一些留言則從實務角度說明，許多反編譯專案本來就是函式一個個替換的「Ship of Theseus」式流程，能分段重建、比對並逐步把 asm 替換成 C，這正是 Decomp Academy 想降低門檻的切入點。