fullseye

讓通用演算法也能實作 — algo-c 對應路線圖

日本語 · English · 简体中文 · 繁體中文 · 한국어 · Deutsch

使用者需求(2026-08-16):https://github.com/okumuralab/algo-c(奧村晴彥 《[修訂新版] C語言標準演算法辭典》全部原始碼)中出現的通用演算法, 也希望能在 Fullseye 中實作。

誠實的現狀認知:Fullseye 目前是 影像演算法設計 AI(op 註冊表 = image/region/ feature/contour/volume 的 sort、演化 + holdout gate + Python→C codegen)。通用演算法 (排序/搜尋/圖論/數論/加密/壓縮)無法歸入影像 sort,因此需要擴充語言、型別與 codegen。 這是橫跨多個工作階段的工作。本文件就是其確定計畫(供下一次工作階段在完整脈絡中執行的正本)。

algo-c 的分類(書籍目錄 · 實作對象地圖)

※ 嚴格的涵蓋範圍以 repo 的 /src 為正本。

領域 代表性演算法 Fullseye 中的承接方式
數值計算 方程式(二分法/Newton)、數值積分(Simpson/Romberg)、線性方程組(Gauss/LU)、內插(spline)、FFT 既有 dsp(FFT)+ 新增 numeric op 族
亂數 · 統計 Mersenne Twister、分布、統計量 新增 rng/stat op(確定性 seed)
排序 quick/heap/merge/shell/radix 新增 array sort + seq 型別
搜尋 二分搜尋、雜湊、BST/AVL/B-tree 新增 array/map op
字串 KMP/BM/Rabin-Karp、編輯距離、正規表示式 新增 text 型別 + op
DFS/BFS、Dijkstra、Warshall-Floyd、MST、最大流 新增 graph 型別 + op
幾何 凸包、線段相交、Voronoi 既有 pcseg/幾何 + 新增 geom2d
數論 · 加密 質數、GCD、RSA、MD5/SHA、AES 新增 numtheory/crypto(教學用 · honest 揭露)
資料壓縮 Huffman、LZ/LZW、算術編碼 新增 compress op
DP/搜尋 8-queens、背包問題、DP fscript 的控制流程 + array

實作架構(確定方針)

將 Fullseye 的既有資產擴充到通用領域。不會稀釋影像 AI 的焦點(通用 op 歸入獨立 tier / opt-in)。

  1. 型別系統擴充:在現有 6+1 種 sort(image/region/feature/contour/match/any/volume)基礎上, 新增seq(一維陣列)/text(字串)/graph/scalar(ops.py 的 sort · fslib 型別)。
  2. fscript 的通用語言化:目前已具備 if/for/while、指派、tuple。將分階段新增陣列/字串 字面量、索引、procedure(函式)(先前決定收窄語言範圍,通用 tier 將以獨立 profile 解禁)。 正本 = 重新檢視 docs/FSCRIPT_DECISION.md 中的 A/B 分支。
  3. op 註冊表擴充:將 algo-c 中的各個演算法以 op(name/in-out sort/params/c_stmt)形式 註冊。直接沿用既有的 Python→C codegen(engine.to_python/to_c)+ difftest(honest gate:以 Python 為 oracle,對 C 做差分驗證)→ 用實測保證「能以 C 實作」
  4. honest gate:把 algo-c 的 C 程式碼作為參考實作餵給 difftest,與 Fullseye codegen 產生的 C 驗證數值/位元一致性(既有 gate 的擴充)。尊重原始程式碼的授權條款(algo-c = 書籍附帶程式碼, 使用條件待確認),不直接照抄,而是從規格重新實作(公開揭露方針)。

階段計畫(下次工作階段以後)

honest 的侷限與規律


P1 完成紀錄(2026-08-16, Opus5[1m]/ultracode)

達成了最小實證「Fullseye 也能為通用演算法產生 C 程式碼,並能 honest 實測出 C 一致性」。

P1 對抗性審查後的強化(2026-08-16, [[feedback_no_solo_ai_judgment]])

對本工作階段自行撰寫的程式碼實施了獨立的對抗性審查(Workflow 4 個視角 = 演算法正確性 / codegen · C 安全 / gate 健全性 / 整合 · 焦點安全,共 22 項 findings)。我對全部結果做了第一手程式碼驗證(v11 規律), 修正了真正的缺陷:

接下來(P2 以後)

P3 完成紀錄 — 字串 op(2026-08-17, Opus5[1m]/ultracode, graph-loop-engineering)

為 algo tier 新增 3 種字串演算法。「字串 = 以 float64 承載 code point 序列」(Unicode 純量 < 2^53 故為 嚴格精確)使其無需改造即可搭載既有的 float64 二進位 harness(無需新 wire 型別)。值僅做相等比較 (整數編碼精確)· 位置/距離為嚴格整數 → C-vs-Python 逐位元一致 且 Python-vs-oracle 為 EXACT(tol 0)

P3 字串 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

獨立對抗性審查 Workflow(4 個視角 · 各項 finding 由驗證代理以實際程式碼/實際 compile 確認)= 3 項 findings 全部 CONFIRMED(其中 2 項是同一根本原因被不同視角分別回報)。經第一手驗證後全部修正:

P2 完成紀錄 — gauss_solve(2026-08-16, Opus5[1m]/ultracode, graph-loop-engineering)

新增線性方程組 Gauss 消去(部分主元),完成 P2 數值計算。 依使用者指示以 graph-loop-engineering 技能將其節點化到 raptor work-graph,讓 tool driver 無人值守執行(雙層方針 = breadth 由 work-graph 的 difftest gate 負責,對抗性 findings 的採納與 push 是工作階段內的人工檢查點)。

P2 gauss 對抗性審查後的強化(2026-08-16, [[feedback_no_solo_ai_judgment]])

對自行撰寫的 gauss 程式碼實施獨立對抗性審查 Workflow(4 個視角 = numeric 正確性 / C 安全 / gate 健全性 / 整合 · 覆蓋,各項 finding 均由驗證代理實際執行重現)。5 項 findings 中 4 項 CONFIRMED,經第一手 程式碼驗證後全部修正:

P1.5b 完成紀錄 — 在 Studio 中以唯讀方式展示 general tier(2026-08-17, Opus5[1m]/ultracode)

在 op 瀏覽器中展示 general(algo)tier。 為不稀釋影像焦點的設計 = general op 屬於 seq/scalar 的 另一套計算模型,故 唯讀(不納入影像流水線)。

P4 完成紀錄 — 圖 op(2026-08-17, Opus5[1m]/ultracode, bonus)

為 algo tier 新增 3 種圖演算法(不在候選之內,但順應使用者「全部推進」+ 7-8h 自律的方針作為 bonus)。 將圖打包進輸入 seq([n, m, (u,v,w)*m],無向;dijkstra 會在前面加上 src 前綴 [n, m, src, ...]), 搭載既有的 float64 harness。

P5 完成紀錄 — 數論 · 壓縮 · 教學用雜湊(2026-08-17, Opus5[1m]/ultracode, graph-loop-engineering)

為 algo tier 新增 5 種通用演算法,完成 algo-c 路線圖(P1→P5)。 整數以 float64 承載(exact < 2^53), 因此不需要新的 wire 型別。位元/整數運算在 C 端 cast 為 unsigned long long/unsigned int 後進行,再 轉回 double(結果 < 2^53 故 exact)。全部 5 個 op 均為 exact(C 逐位元一致,且 Python==獨立 oracle tol 0)。

P5 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

對自行撰寫的 P5 程式碼實施獨立對抗性審查 Workflow(4 個視角 = algorithm-correctness / C-safety-codegen / gate-honesty / integration-focus,各項 finding 均由驗證代理以實際 compile/執行重現,18 個 agent)。14 項原始 → 9 項 CONFIRMED / 5 項 REFUTED。全部 CONFIRMED 均由我第一手重現(親自用 ziglang 編譯 · 執行)後修正。尤其值得一提的是對「gate 是否能證偽自身守衛」這一點的深入追問:

P6 完成紀錄 — 計算幾何(2026-08-17, Opus5[1m]/ultracode, 12h 自律 · graph-loop-engineering)

為 algo tier 新增 3 種幾何演算法(algo-c 路線圖 P1→P5 完成後的擴充 = P6。對應最初 TOC 中的 「幾何 = 凸包/線段相交」)。也是通向影像 tier 中輪廓/區域處理的橋梁。將 2-D 點打包進輸入 seq,用整數座標(各 [-100000, 100000])使全部方向判定/鞋帶和都成為嚴格整數運算(完全不使用 浮點除法)= C 逐位元一致,且 Python==獨立 oracle tol 0。

P6 對抗性審查(2026-08-17, [[feedback_no_solo_ai_judgment]])

並行實施了 2 場獨立對抗性審查 Workflow(各項 finding 均由驗證代理以實際 compile/執行/壓力測試重現):

P7 完成紀錄 — 線段相交(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

幾何工具集擴充 1 個 op:segments_intersect(KIND_REDUCE)= 判定 2 條封閉線段 [x1,y1,x2,y2,x3,y3,x4,y4] 是否相交(1.0/0.0)。是通向影像的直線/輪廓分析的橋梁。採用 CLRS 33.1 的整數方向判定法(proper crossing = 端點嚴格跨越對方線段 + 4 個共線 on-segment 特殊情形)。整數 座標 [-100000,100000] 下叉積嚴格精確(|cross| ≤ 8e10 可放入 long long)= C 逐位元一致。oracle = sympy.geometry 的 Segment 相交判定(符號運算 = 與方向判定完全不同的方法)。實測:8 個固定情形 全部正確 + 與 sympy 在 2970 組隨機整數線段對上不一致數為 0(含共線重疊/T 字形/共享端點/near-miss)。 退化(點)線段因 sympy 無法建構 Segment,已從 holdout 中排除(op 本身用通用方向判定邏輯可處理,但 未納入 gate = 已揭露)。difftest passed(python exact / C 逐位元一致 / c_verified),work-graph 節點 無人值守完成(全部 algo op 達到 24 個 · 已 gate 化)。

P7 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

3 個視角的對抗性審查(驗證代理以實際 compile/執行重現)= 1 項原始 → 1 項 CONFIRMED(MED · gate-honesty)。op 本身正確(與 sympy 完全一致),但difftest holdout 從未以單獨理由驅動過 d1/d3/d4 的 on-segment 特殊情形(端點落在對方線段內部 = 無共享端點),導致刪除該分支的錯誤 op 能通過 gate(50 個 holdout 的判定結果一個也沒變化)。已自行重現確定(丟棄 d3+d4 的變異體 passed=True ·[0,0,10,0,3,0,3,5]→錯誤得到 0.0)。修正=為各 on_seg 分支(d1/d2/d3/d4)新增以 單獨理由驅動的固定 holdout 情形(端點在對方線段內部 · 軸平行 4 個 + 對角 2 個)→ 已自行確認任意 丟棄 d1/d2/d3/d4 中的一個分支都會使 difftest FAIL(均為 passed=False)。已知解測試中也新增了 4 個端點-內部情形。全部套件從 4765 增至 4772 passed / 0 failed(+7)· ruff clean · mypy 新增 0。

P8 完成紀錄 — 搜尋/選擇(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

為 algo tier 新增 2 種搜尋/選擇演算法(從幾何轉向另一個領域以均衡 tier)。基於比較,可處理任意 (NaN-free)double,結果為 index 或既有元素,故 exact(tol 0)· C 逐位元一致。

P8 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

2 個視角的對抗性審查(實際 compile/執行驗證)= 1 項原始 → 1 項 CONFIRMED(LOW · correctness)。 正確性不變,但存在效能缺陷:kth_smallest 的 quickselect 因單一 pivot(Lomuto)而在 all-equal/低基數大輸入下呈 O(n²)(median-of-three 無法保護重複值 · n=40000 全相等時耗時 7.44s,sorted/reverse 則很快)。測試的 holdout 僅 n≤30、計時測試只有 sorted 情形,未能捕捉。 姊妹 op quicksort 已在使用 3-way(Dutch flag)分割。修正=將 kth_smallest 改寫為 3-way(Dutch national flag)分割(用 equal-band 把重複值折疊 → 使 all-equal 變為 O(n) · 僅用 比較且與順序無關 → 維持 C==Python==sorted()[k] 的 parity)。已自行重現確認:all-equal n=40000 從 7.44s 降至 0.0019s(實現 O(n) 化)· correctness 的 5000 組情形不一致數為 0 · difftest 逐位元一致。計時測試已擴充到 sorted/reverse/all_equal/few_distinct(實際防護退化)。

P9 完成紀錄 — 統計/彙總(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

為 algo tier 新增 2 種統計 op:count_distinct(去重值數量 = 整數 count)/ mode_value (眾數 · 值較小者優先 tie)。均基於比較(任意 NaN-free double),結果為 count 或既有元素,故 exact (tol 0)。兩個 op 均先複製並排序,再做單趟掃描(結果與順序無關,故即使 C 的 qsort 與 Python 的 sorted 順序不同也逐位元一致)。oracle=len(set()) / collections.Counter(獨立機制)。 ★主動強化:當 mode_value 的眾數為零且 ±0.0 混雜時,C 的不穩定 qsort 與 Python 的穩定 sort 可能 回傳正負號不同的值而導致逐位元不一致 → 用 + 0.0 把 −0.0→+0.0 正規化(其他值不變)使 C==Python 更加穩健(與 rle_encode 的帶正負號零揭露同屬一類)。實測:各 5000 組隨機情形與 oracle 的不一致數為 0 · difftest passed(python exact / C 逐位元一致 / c_verified)。全部 algo op 達到 28 個 · 已 gate 化。 ruff clean · mypy 新增 0。

P9 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

2 個視角的對抗性審查(實際 compile/執行/變異驗證)= 1 項原始 → 1 項 CONFIRMED(MED · gate-safety)。正確性不變,但存在 gate 覆蓋缺口:holdout 無法證偽刪除 mode_value 的 +0.0 正規化這一變異體(唯一的帶正負號零情形 [0.0,-0.0,0.0] 在兩個 backend 中都被排序為 +0.0 在末尾, 刪除正規化也仍然逐位元一致)。註解聲稱能擔保的逐位元檢查從未真正驅動過該正規化。修正=在 holdout 中新增 -0.0 不落在 run 末尾的情形 [0.0,-0.0]·[-0.0,0.0](兩種順序,無論 qsort 的 tie 順序如何 必有一方會發散)。已自行重現確認:刪除正規化的變異體使 difftest FAIL,現行(已正規化)程式碼在 新增情形下逐位元一致 pass。全部套件從 4787 增至 4796 passed / 0 failed

P10 完成紀錄 — 數論(第2部分)(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

新增 2 種數論 op(建立在 P5 的整數機制之上 · 共享 category numtheory)。整數以 float64 承載 (exact <2^53)· 在 honest 域內全部模乘積都能放入 uint64/long long = C 逐位元一致,且 Python==獨立 oracle tol 0。

P10 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

2 個視角的對抗性審查(實際 compile/執行/變異驗證)= 1 項原始 → 1 項 CONFIRMED(MED · c-safety-gate)。op 本身正確且 overflow-safe(已用 353 個敵對情形驗證),但 modular_inverse 的 holdout 未驅動到宣告域 2^53(in-domain 的 m 最大只到約 1e9),使 C 的 long long→int 窄化變異體(破壞 2^53 域)能以逐位元一致通過 gate。姊妹 op pow_mod(base=exp 已固定在 2^53)/ gcd_seq(已固定 2^53 守衛邊界)/ is_prime(近 2^32)都能捕捉同類變異體,唯獨 modular_inverse 未涵蓋。修正=在 holdout 中新增 2^53 邊界情形([2, 2^53−1] coprime → inverse · 接近 2^53 的大 coprime 值 · [2^52, 2^53] 均為偶數 → −1,使 Bezout 運算驅動 |q·s|~2m~2^54)。已自行重現確認: long long→int 變異體使 difftest FAIL,baseline 逐位元一致 pass。oracle(pow)已經能對應,故僅 新增 holdout。全部套件全綠。

P11 完成紀錄 — 位元運算(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

新增 2 種位元運算 op:xor_reduce(全部元素的位元 XOR)/ popcount_total(全部元素的 1 位元總數 = Kernighan 演算法)。用 float64 承載非負整數,域 [0, 2^53−1] 內全部值可放入 53 位元(XOR 結果也 < 2^53=exact · popcount 是較小整數)= C 逐位元一致,且 Python==獨立 oracle (functools.reduce(operator.xor) / 內建 int.bit_count() = 與 Kernighan 不同的機制)tol 0。 兩個 op 均為 passed=True · python exact / C 逐位元一致 / c_verified。已事先用各 3000 組隨機情形與 oracle 核對不一致數為 0。fail-soft = 負數/非整數/≥2^53 時為 0.0。全部 algo op 達到 32 個 · 已 gate 化。ruff clean(以 FURB161 將 bin().count('1').bit_count() 化)· mypy 新增 0。

P11 對抗性審查結果(2026-08-17, [[feedback_no_solo_ai_judgment]])

2 個視角的對抗性審查 Workflow(correctness + gate-safety,wf_7d130631-c0f)= findings 0 (無缺陷)。審查者 1 得到 {findings:[]},審查者 2 在做「gate mutation testing(破壞實作看 gate 能 否抓到)」過程中因 window 壓縮而中斷(未產出結果)。依規律不去復活死掉的 background,而是由我 用同樣的 mutation test 親自第一手完成驗證:對 xor_reduce/popcount_total 的代表性 7 種變異體(空 初始化 acc=1 / 誤用 OR / 2^53 域邊界 off-by-one / 刪除負數守衛 / Kernighan→shift[popcount≠bitlength] / +2 誤差 / admit 2^53)在 holdout 上執行 → 全部 7 種變異體均被獨立 oracle 捕捉(oracle_err > 0)。結論 = P11 的 gate 可證偽 · 未發現確定缺陷(fed093a 正當、無需 follow-up commit)。

P12 完成紀錄 — 擴充歐幾里得演算法(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

新增 1 種數論 op(建立在 P5 的整數機制 + P10 的 Bezout 不變量之上 · 共享 category numtheory=P5+P10+P12)。extended_gcd(KIND_MAP):輸入 [a, b](非負整數 ≤ 2^53)→ 輸出 [g, x, y](嚴格 3 值,滿足 a·x + b·y = g = gcd(a,b)),域外為 [] fail-soft。用迭代版 two-variable sweep 計算係數。係數為嚴格精確(不變量 |q·s| = |old_s − new_s| ≤ 2·max(a,b) ≤ 2^54 能放入 C 的 long long)故 C==Python 逐位元一致。域為 [0, 2^53] 含端點(2^53 為 exact · 係數 |x|,|y| ≲ 2^52 在 float64 也是 exact)。

P12 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

3 個視角的對抗性審查 Workflow(correctness / c-safety+gate-honesty / integration,各項 finding 均由 驗證代理以實際 compile/執行的 mutation 重現,5 個 agent · 125 次工具呼叫)= 2 項原始(同一 根本原因)→ 1 項 CONFIRMED(MED · gate-cannot-falsify)。op 本身正確(已在 20 萬組 + 全部端點 上驗證 · 與遞迴 oracle 不發散 · 域內無 long long overflow),但difftest holdout 的域外情形全部 集中在 operand a 一側([2^53+2,3]/[2.5,7]/[-1,7]),唯一的 bad-b 情形 [7,NaN] 因 NaN 在 bd>=0.0 處即短路,一次也沒能單獨驅動 b 的 3 個守衛分支 → b 側守衛的單側退化(a/b 是 複製對稱程式碼,因而看似合理)能同時穿過兩個 gate 的一半(與 P5/P7/P9/P10 相同的 gate-coverage 教訓)。自行重現確定:從 _PY/_C 兩側同時刪除 bd>=0/bd<=2^53/bd==int全部 passed=True(未被捕捉),而對稱的 a 側刪除全部 passed=False(已被捕捉 · 因 a 的域端在 holdout 中)。修正=在 holdout 與 fail-soft 測試中新增 [valid_a, finite_bad_b] 情形 ([3, 2^53+2]·[7,-1]·[7,2.5])→ 重新實測後 b 側 3 處刪除全部被捕捉(passed=False, pydiff=inf)、baseline 在 70 個用例上逐位元一致 pass。★採納驗證代理的 honest 修正(駁回 finding 中的過度斷言):「刪除 bd<=2^53 會使 b=2^62 時 C long long 發生 overflow UB」這一說法不準確 ——b=2^62 時 C(long long)與 Python(bignum)逐位元一致(無 overflow)。真正的問題是輸出的精度 損失(Bezout 係數在 > 2^53 時無法用 float64 嚴格表示,導致 a·x+b·y==g 被破壞),b<=2^53 的 上限正是為守護此精度。機制描述有誤,但缺陷本身與修復方案成立 = 予以採納。

P13 完成紀錄 — 最近點對(分治法)(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

幾何工具集再擴充 1 個 op(P6/P7 之後的第 2 彈):closest_pair(KIND_REDUCE)= 用分治法 (CLRS 33.4)求 2-D 整數點集的最小平方距離。輸入 [x0,y0,x1,y1,...](2n 個 · 整數座標 [-1e5,1e5])→ 輸出 = 最小平方歐氏距離(整數嚴格精確)。僅用平方距離(不開根號),故封閉於 long long/整數 float64,C==Python 逐位元一致。最大平方距離 = (2e5)²×2 = 8e10 < 2^53=exact。 fail-soft = 點數 <2(n<4)/ 長度為奇數 / 座標非整數或超出 [-1e5,1e5] 域 → -1.0。

P13 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

3 個視角的對抗性審查 Workflow(correctness / c-safety+gate-honesty / integration,各項 finding 均由 驗證代理以實際 compile/執行的 mutation 重現)= 3 個視角收斂到同一根本原因 → 1 項 CONFIRMED (severity = 我最初評為 MED / 驗證代理評為 HIGH,認為 gate-honesty 失敗[gate 會 green-light 錯誤 op]更嚴重。作為 honest 揭露兩種評價並陳,修正內容相同)。op 本身正確(在 3 萬+1.6 萬組敵對情形 上與暴力法不一致數為 0),但difftest holdout 從未驅動 strip 的 y-scan 超過 immediate neighbor(j==i+1)→ 將 strip 前向掃描收窄至僅 j==i+1 的退化能被 gate 放行(因 7 近鄰定理指的是 「至多 7 個」而非「恰好 1 個」,按 y 序存在非相鄰的最近點對是可能的)。自行重現確定:將掃描範圍 收窄為 range(i+1, min(i+2, sc)) 的 mutation 同時套用到 _PY/_C → passed=True(未被捕捉)。已在 整數網格中搜尋並發現能證偽該缺陷的最小情形(例如 [0,-6,-2,-2,4,-3,-5,3]= 最近點對在 y 序上相隔 2 個位置 → 完整/暴力法得 20,而僅 j==i+1 得 25)。修正=在 holdout 與已知值測試中新增 strip 內 最近點對在 y-sorted 中非相鄰的 3 種情形([0,-6,-2,-2,4,-3,-5,3]→20 / [-4,5,-1,-3,0,-1,3,-3]→5 / [-1,-6,-1,0,-5,-4,1,-4,4,4]→8)→ 重新實測確認 j==i+1-only 的 mutation 被捕捉(passed=False, pydiff=12)、baseline 在 61 個用例上逐位元一致 pass、其他 5 個 mutation 無回歸。在既有的 6 種 mutation(省略 strip/sq 忽略 y/座標上下限/整數性/空 strip)基礎上, strip 掃描深度也變得可證偽(將 P12 的 gate-coverage 教訓擴展到幾何領域的 strip 掃描)。

P14 完成紀錄 — Huffman 最佳前綴編碼成本(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

資料壓縮再擴充 1 個 op(P5 的 rle_encode 之後的壓縮第 2 彈):huffman_cost(KIND_REDUCE)= 給定 符號頻率 [f0,f1,...](非負整數 ≤2^40),求最佳前綴(Huffman)編碼的最小總成本(=全部內部節點 合併權重之和 = Σ freq×編碼長度)。★核心 = 最佳成本對 tie 不變(每個符號的編碼長度會隨 tie 打破方式改變,但總成本由頻率多重集合唯一決定),故即使 C 與 Python 以不同順序取出等權元素, 總和依舊相同 = 逐位元一致能乾淨地成立。整數用 long long 承載(透過域守衛約束在 < 2^54,無 overflow)。

P14 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

3 個視角的對抗性審查 Workflow(correctness / c-safety+gate-honesty / integration,各項 finding 均由 驗證代理以實際 mutation 重現)= 3 項 CONFIRMED(均為 merge overflow bail 邊界的 gate-coverage 問題 · op 本身正確、tie 不變性也已在 5 萬+4000+2 萬組資料上確定)。correctness 相關 的指摘為 0(tie 不變性的主張、兩佇列法的最佳性均穩健)。CONFIRMED 全部集中在「merge-total>2^53 的 fail-soft 邊界」的覆蓋上:

P15 完成紀錄 — 最長遞增子序列長度(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

搜尋/選擇再擴充 1 個 op(P8 binary_search/kth_smallest 之後的搜尋第 2 彈 · DP/patience sorting 新演算法族):lis_length(KIND_REDUCE)= 用 patience sorting 求任意 NaN-free double 數列的 最長嚴格遞增子序列(LIS)長度。僅用比較(不對值做算術運算),故長度由陣列本身唯一確定 = C==Python 逐位元一致。tails[k] 保存長度 k+1 的遞增子序列的最小結尾,對每個元素在 tails[mid] < x(bisect_left · 嚴格)位置替換或延伸結尾(O(n log n))。空 → 0.0,混有 NaN → -1.0 fail-soft(用 x != x 偵測)。

P15 對抗性審查結果(2026-08-17, [[feedback_no_solo_ai_judgment]])

3 個視角的對抗性審查 Workflow(correctness / c-safety+gate-honesty / integration,mutation 驗證)= findings 0(全部視角均無指摘)。已驗證 patience sorting 的嚴格比較 · NaN 守衛 · tails 緩衝區安全 · O(n²) DP oracle 的獨立性 · holdout 單獨驅動嚴格比較的能力,未偵測到可證偽的缺陷。 事先的 mutation 3/3 全部被捕捉(嚴格 <<=/NaN 守衛/二分方向)與 4 萬組 DP 一致,說明 gate 穩健。

P16 完成紀錄 — 逆序數(合併排序法)(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

統計再擴充 1 個 op(P9 count_distinct/mode_value 之後的統計第 2 彈):count_inversions (KIND_REDUCE)= 用計數合併排序以 O(n log n) 求任意 NaN-free double 數列的逆序數 (i<j 且 a[i] > a[j] 的嚴格對數)。僅用比較(不對值做算術運算),故 count 由陣列本身唯一確定 = C==Python 逐位元一致。合併時每當右列先取出一個元素,就把左列剩餘數量累加(經典做法)。count 為 非負整數,故 -1.0 是安全 sentinel:NaN→-1.0 fail-soft,空/單元素→0.0。相等值不算逆序(tie 時 先取左邊 = arr[i] <= arr[j])。

P16 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

★worktree 隔離審查首次成功應用:3 個視角 × 隔離 git worktree(各代理從 cd76da0 建立各自 專用副本並做 mutation)→ 本 repo 的 algo.py 始終保持乾淨(驗證代理也明確記錄「real repo 為 唯讀 · 在隔離 worktree 中做 mutation · 已清理善後」)。結構性解決了 P14 的汙染問題。結果 = 2 項 CONFIRMED(均為 LOW) · correctness 相關為 0(op 正確):

P17 完成紀錄 — 最大子陣列和(Kadane 演算法)(2026-08-17, Opus5[1m]/ultracode, 12h 自律)

搜尋/最佳化再擴充 1 個 op(P8 binary_search/kth_smallest · P15 lis_length 之後的搜尋第 3 彈):max_subarray(KIND_REDUCE)= 對整數值 double 數列用 Kadane 的 O(n) 重置掃描 (cur = max(0, cur+x); best = max(best, cur))求連續子陣列的最大和允許空子陣列 (和為 0),故答案恆 ≥ 0(全負時為 0.0)= -1.0 是安全 sentinel。在整數域內(各 |x| ≤ 2^52 且絕對值的滾動和 ≤ 2^52)使全部部分和都保持在嚴格整數 < 2^53 → 答案嚴格精確 · C==Python 逐位元一致。獨立 oracle(全部 O(n²) 子陣列的暴力最大值)因整數加法的結合律而與 Kadane 嚴格一致。fail-soft -1.0 = NaN / inf / 非整數 / |x| > 2^52 / 滾動和溢位。

P17 對抗性審查後的強化(2026-08-17, [[feedback_no_solo_ai_judgment]])

worktree 隔離審查(4 個 agent · 3 個視角 + 對抗性驗證)= 1 項 CONFIRMED(LOW · gate-honesty)/ refuted 0。驗證代理在隔離 worktree 中完整重現,並明確記錄本 repo 的 algo.py 未被汙染(status --porcelain 只有 auto 的 SESSION_SUMMARY)。correctness/integration 相關為 0 (op 正確):

2026-09-03:對抗性審查(algo + C codegen)的 8 項修正