分页: 3 / 5

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 09:09
ejsoon
當shooting取勝時,預估勝率應為100%,現在顯示0%,分析原因,並給出解決辦法。

代码: 全选

這是一個邏輯判斷上的錯誤。原因在於 `applyMove` 函數回傳的 `terminal` 狀態與 `winner` 的歸屬判斷在「當前玩家執行最後一擊」時,與 MCTS 的評分 logic 產生了衝突。

### 原因分析

在您的程式碼中:
1. **`applyMove` 的邏輯**:當一個動作導致勝負分出(例如綠方過橋達到 12 座或藍方無處可走),`applyMove` 會回傳 `terminal: true` 並設置 `winner`(0 或 1)。
2. **`runMCTS` 的邏輯**:
   ```javascript
   let res = applyMove(rootState, move);
   if (res.terminal) {
       // 這裡原本寫死為 immediateLoss: true
       moveStats.push({ move, wins: -999, plays: 1, immediateLoss: true });
   }
   ```
   問題就在這裡:程式碼**預設所有 `terminal` 都是「我被殺了」**。但實際上,如果這個 `terminal` 是由我方走出的「絕殺一步」(Shooting),`res.winner` 就會是我自己。此時應該判定為 **100% 勝率**,而不是 0%。

---

### 解決辦法

我們需要修改 `runMCTS` 中處理 `res.terminal` 的部分,根據 `res.winner` 是否等於當前移動者 (`rootState.turn`) 來判斷是「絕殺對方」還是「自殺/被困」。

#### 修改 `runMCTS` 核心判斷區塊:

請找到 `runMCTS` 函式中處理 `res.terminal` 的 `if` 語句,替換為以下邏輯:

```javascript
            // 核心推演邏輯
            let res = applyMove(rootState, move);
            
            if (res.terminal) {
                // 修改處:判斷贏家是誰
                if (res.winner === rootState.turn) {
                    // 如果贏家是我,這是一步絕殺(Shooting 取勝)
                    moveStats.push({ move, wins: Infinity, plays: 1, guaranteedWin: true });
                } else {
                    // 如果贏家不是我(或平局 -1),則視為失敗
                    moveStats.push({ move, wins: -999, plays: 1, immediateLoss: true });
                }
            } else if (canForceWin(res.state, 2, rootState.turn)) { 
                // ...其餘邏輯不變
```

#### 同步更新 `renderMctsResults` (或結果處理部分):

為了讓 UI 顯示得更清楚,當 `guaranteedWin` 為真時,確保勝率計算正確。

在顯示勝率的邏輯中(不論是 `isAuto` 還是 `renderMctsResults`),確保優先檢查 `guaranteedWin`:

```javascript
// 在 renderMctsResults 或 isAuto 結束判斷時
let scoreText = "";
if (stat.guaranteedWin) {
    scoreText = "<span style='color:green'>🎯 100% (絕殺/必勝)</span>";
} else if (stat.immediateLoss) {
    scoreText = "<span style='color:red'>💀 0% (致命錯誤)</span>";
} else if (stat.guaranteedLoss) {
    scoreText = "<span style='color:orange'>⚠️ 0% (必敗走法)</span>";
} else {
    scoreText = `勝率: ${((stat.wins / stat.plays) * 100).toFixed(1)}%`;
}
```

### 為什麼這能解決問題?
1. **Shooting 取勝辨識**:當執行走棋後滿足勝利條件,`res.winner` 會等於 `rootState.turn`。
2. **優先權排序**:透過將 `wins` 設為 `Infinity` 並標記 `guaranteedWin: true`,這步棋會被排在最前面,且自動走棋會毫不猶豫地執行這一步。
3. **消除誤報**:不再將所有結束遊戲的動作都視為「失敗」,讓 AI 能夠正確識別自己的勝利動作。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 09:44
ejsoon
konigsberg20260411autoplay778

更改長寬顯示邏輯,AI計算改進。

https://ejsoon.vip/wp-content/uploads/2 ... ay778.html

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 10:05
ejsoon
在以下局面中,要能算出藍方有必殺走法:

[[9,4,3,0,4,0,5,4,5,9,9,8,2,6,2,1,0,1,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7]]

在僅有的幾步棋中,「9,8,4,0」或「9,8,4,0,1」都能形成殺棋,但是這個程式卻算出它的勝率很低,分析原因並給出解決辦法。

只需給出所要修改的地方。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 10:07
ejsoon
grok:

代码: 全选

```html
<!-- ONLY THE FOLLOWING SECTIONS OF THE ORIGINAL JAVASCRIPT CODE NEED TO BE REPLACED -->
<!-- All code and comments below are in English as required -->

/*
### About adjustable parameters (PARAMS)

1. SIMULATIONS_PER_MOVE (default 50):
   * Determines how many random playouts are run per candidate move.
   * Larger values give more reliable win rates but may cause brief lag if set above 500.

2. MAX_DEPTH (default 8):
   * Maximum simulation depth for random playouts. Beyond this depth the game is treated as a draw.

3. MAX_PATH_LENGTH (default 10):
   * Maximum number of steps a single move is allowed to take.

4. FORCE_CHECK_DEPTH (default 6) [NEW]:
   * Depth used by the exact forced-win minimax (canForceWin) to detect "must-kill" sequences.
   * The original hardcoded value of 2 was too shallow to recognize forced wins that require 3–4 perfect replies.
   * Setting it to 6 allows the AI to correctly identify deep killing moves (e.g. the 9-8-4-0 and 9-8-4-0-1 lines) while still being fast because the root usually has very few legal moves.
*/

const PARAMS = {
    SIMULATIONS_PER_MOVE: 50, 
    MAX_DEPTH: 8,
    MAX_PATH_LENGTH: 10,
    FORCE_CHECK_DEPTH: 6   // NEW: deeper exact search for forced wins/losses
};
```

```javascript
// In runMCTS function – replace the block that evaluates each root move
// (the part after "let res = applyMove(rootState, move);" )

            let res = applyMove(rootState, move);
            if (res.terminal) {
                if (res.winner === rootState.turn) {
                    // If winner === rootState.turn (should never happen for terminal moves,
                    // but kept for safety)
                    moveStats.push({ move, wins: Infinity, plays: 1, guaranteedWin: true });
                } else {
                    moveStats.push({ move, wins: -999, plays: 1, immediateLoss: true });
                }
            } else if (canForceWin(res.state, PARAMS.FORCE_CHECK_DEPTH, rootState.turn)) { 
                // Changed from hardcoded 2 to PARAMS.FORCE_CHECK_DEPTH
                // This now correctly detects the forced win after moves like [9,8,4,0]
                // or [9,8,4,0,1] because the minimax can look far enough ahead.
                moveStats.push({ move, wins: Infinity, plays: 1, guaranteedWin: true });
            } else if (canForceWin(res.state, PARAMS.FORCE_CHECK_DEPTH, 1 - rootState.turn)) {
                // Changed from hardcoded 2 to PARAMS.FORCE_CHECK_DEPTH
                moveStats.push({ move, wins: -500, plays: 1, guaranteedLoss: true });
            } else {
                let wins = 0;
                for (let i = 0; i < PARAMS.SIMULATIONS_PER_MOVE; i++) {
                    let winner = playout(res.state, PARAMS.MAX_DEPTH);
                    if (winner === rootState.turn) wins += 1;
                    else if (winner === -1) wins += 0.5;
                }
                moveStats.push({ move, wins, plays: PARAMS.SIMULATIONS_PER_MOVE });
            }
```

```javascript
// The canForceWin function itself does NOT need any change – it is already correct.
// The only reason the original code failed to see the killing move was the
// insufficient depth (hardcoded 2) and the fact that random playouts (playout())
// do not follow the perfect forcing line, leading to artificially low win rates.
```

**Reason for the original low win-rate bug (English explanation):**

- The move `[9,8,4,0]` (or `[9,8,4,0,1]`) places the blue man in a position where the green player has no safe reply: every possible green move either gets immediately shot or leads to a position where blue can force a win a few moves later.
- With the original `canForceWin(..., 2, ...)` the search was too shallow to see the full forced sequence.
- Random playouts also underestimated the position because the playout policy is purely random and does not choose the precise replies needed to keep the forcing line alive. Hence the reported win rate was very low even though it is a guaranteed win.

**Solution summary (already implemented in the patches above):**

Only the two places that called `canForceWin` with the magic number `2` were changed to use the new `PARAMS.FORCE_CHECK_DEPTH: 6`. This makes the AI instantly recognize the killing move as `guaranteedWin: true` while keeping the rest of the code untouched. No other functions need modification.

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 10:34
ejsoon
gemini pro:

代码: 全选

### 分析原因

這個問題的根本原因在於 **AI 尋找「必勝/必敗步」的預測深度(Depth)太淺**。

在您給出的盤面中,藍方走 `[9, 8, 4, 0]` 的必殺邏輯屬於「關門捉賊」。藍方走完後,綠方並不會立刻死亡,而是被迫退到死角(例如節點 7)。接著藍方需要在下一回合進行「封堵」(例如走到節點 4),最後綠方才會因為「無路可走」而判定敗北。

這整個陷阱的發酵過程需要 **3 到 4 步(Plies / 半回合)** 才能完全展現(藍方動 ➔ 綠方逃 ➔ 藍方堵 ➔ 綠方無路可走)。

然而,在程式碼的 `runMCTS` 函數中,窮舉必殺走法的 `canForceWin` 函數**搜索深度被寫死為 `2`**。因為它只能往後看 2 步,所以它看不到綠方最終會被困死,於是判定這不是必殺步,並將其交給後續的 `playout()`(隨機推演)來計算勝率。在隨機推演中,藍方有可能隨機走到錯誤的節點導致自己被反殺,這就導致了原本是 100% 必殺的棋,卻算出了極低的平均勝率。

---

### 解決辦法

只需將 `runMCTS` 函數中,呼叫 `canForceWin` 的深度參數由 `2` 改為 `4`(或 `5`),讓 AI 能夠往後預見更深的必殺陷阱即可。

**所要修改的地方:**
在程式碼中找到 `runMCTS` 函數,修改這幾行程式碼:

```javascript
            // 修改前:
            } else if (canForceWin(res.state, 2, rootState.turn)) { 
                moveStats.push({ move, wins: Infinity, plays: 1, guaranteedWin: true });
            } else if (canForceWin(res.state, 2, 1 - rootState.turn)) {
                moveStats.push({ move, wins: -500, plays: 1, guaranteedLoss: true });
            } else {
```

```javascript
            // 修改後 (將 2 改成 4):
            } else if (canForceWin(res.state, 4, rootState.turn)) { 
                moveStats.push({ move, wins: Infinity, plays: 1, guaranteedWin: true });
            } else if (canForceWin(res.state, 4, 1 - rootState.turn)) {
                moveStats.push({ move, wins: -500, plays: 1, guaranteedLoss: true });
            } else {
```

修改完成後,AI 就能在深度 4 的窮舉中正確識破綠方未來會「無路可走」,從而將 `[9, 8, 4, 0]` 與 `[9, 8, 4, 0, 1]` 正確標示為 <span style='color:green'>🎯 必殺走法</span>。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 12:28
ejsoon
贏了一場778:

代码: 全选

[[3,6],[-5,3,0,1,5,9,8,4,7],[7,6,0,3,1,0,5,1,9,5,8,9,4,8,7,4],[-5,6,9,5,4,8],[7,8,0,3,1,0,5,1,5,9,8,9,8,4,7,4,9,6,4,5],[-5,7,4,0,3],[3,8,3,0,1,0,5,1,5,9,8,9,8,4,4,7,9,6,4,5,0,4],[-5,8,5,1,4,3,0],[3,0,0,3,1,0,1,5,5,9,8,9,8,4,4,7,9,6,4,5,0,4,5,8,4,1,4,3],[-5,3,7,8,4,1],[1,0,0,3,1,0,1,5,5,9,8,9,4,8,4,7,9,6,4,5,0,4,5,8,1,4,4,3,3,7,7,8],[-5,0,4,5,8,9,6,2],[1,2,0,3,1,0,1,5,5,9,9,8,4,8,4,7,6,9,5,4,4,0,8,5,1,4,4,3,3,7,7,8,6,2],[-5,1,2,5,4],[4,2,0,3,1,0,1,5,5,9,9,8,4,8,4,7,6,9,4,5,4,0,8,5,1,4,4,3,3,7,7,8,6,2,1,2,2,5],[-5,2,5],[4,5,0,3,1,0,1,5,5,9,9,8,4,8,4,7,6,9,4,5,4,0,8,5,1,4,4,3,3,7,7,8,6,2,1,2,2,5],[-1,4,7,4,3,4,8,4,0,4,5,7,8,3,7,8,5,0,3,5,9,9,8]]

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 12:42
ejsoon

代码: 全选

[[9,4,3,0,4,0,5,4,5,9,9,8,2,6,2,1,0,1,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,9,8],[8,4,3,0,4,0,5,4,5,9,8,9,2,6,2,1,0,1,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,4,0,1],[8,1,3,0,0,4,5,4,5,9,8,9,2,6,2,1,1,0,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,8,9],[9,1,3,0,0,4,5,4,5,9,9,8,2,6,2,1,1,0,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,1,4,8,7],[9,7,3,0,0,4,5,4,5,9,9,8,2,6,2,1,1,0,3,4,4,7,7,8,5,8,5,1,2,5,5,6,6,9,1,4,3,7,4,8]]
檢測出function applyMove(state, route)有誤。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 12:53
ejsoon
konigsberg20260411tipswindow7781

加上了絕殺層數,某些局面能算到終局了。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 13:05
ejsoon
在以下局面中:

[[9,4,3,0,4,0,5,4,5,9,9,8,2,6,2,1,0,1,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,9,8],[8,4,3,0,4,0,5,4,5,9,8,9,2,6,2,1,0,1,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,4,0,1],[8,1,3,0,0,4,5,4,5,9,8,9,2,6,2,1,1,0,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,8,9],[9,1,3,0,0,4,5,4,5,9,9,8,2,6,2,1,1,0,3,4,4,7,8,7,5,8,5,1,2,5,5,6,6,9,1,4,3,7],[-5,1,4,8,7],[9,7,3,0,0,4,5,4,5,9,9,8,2,6,2,1,1,0,3,4,4,7,7,8,5,8,5,1,2,5,5,6,6,9,1,4,3,7,4,8],[-5,9,8],[8,7,3,0,0,4,5,4,5,9,8,9,2,6,2,1,1,0,3,4,4,7,7,8,5,8,5,1,2,5,5,6,6,9,1,4,3,7,4,8]]

綠方直接射殺,應判其勝率為100%。但是現在勝率卻是0。

請查找原因。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 13:16
ejsoon
gemini pro:

代码: 全选

這是一個非常敏銳的觀察!導致這個現象的根本原因在於 **MCTS 演算法與真實遊戲判定機制的「觸發時機」產生了落差**。

簡單來說:**MCTS 演算法遺漏了對「初始盤面(Root State)是否已經是必勝局面」的檢查,強迫綠方必須「走出一步」,從而放棄了原本的絕殺機會。**

以下為您詳細拆解原因與修復方式:

### 🔍 盤面狀態分析
根據您提供的歷史紀錄,我們檢視最後一步的狀態:
`[8, 7, 3,0, 0,4, 5,4, 5,9, 8,9, 2,6, 2,1, 1,0, 3,4, 4,7, 7,8, 5,8, 5,1, 2,5, 5,6, 6,9, 1,4, 3,7, 4,8]`
* **藍方 (p0)** 位於點 `8`
* **綠方 (p1)** 位於點 `7`
* 現存橋樑中包含一條 **`7 -> 8`** 的路徑。

在真實遊戲的邏輯中(`judgeResult` 函數),當輪到綠方回合且綠方點擊自己的棋子時,系統會**立刻**透過連通性檢查發現綠方(7)可以直接攻擊藍方(8)。這時遊戲會直接判綠方獲勝,**綠方根本不需要、也不能進行任何移動**。

### 🐞 為什麼 MCTS 算出版勝率是 0%?
當您在這個局面點擊「開始搜尋」時,MCTS 會執行 `getLegalMoves(rootState)`。
在這個函數中,有一條嚴格的規則:
```javascript
if (path.length > 1 && ...) { moves.push(path.slice()); }
```
這意味著 MCTS **強迫綠方必須至少移動一步**(產生一條路徑)。
當綠方被迫離開點 `7`(例如移動到 `4`),他不僅主動放棄了原本 `7 -> 8` 的絕殺機會,還可能因為移動導致橋樑翻轉,讓自己暴露在藍方的射擊範圍內。

因為所有「移動」都會破壞這個已經到手的勝利,甚至導致自己被反殺,所以 MCTS 評估後得出「只要綠方移動,勝率就是 0%」的結論。它的計算沒有錯,只是它不知道綠方有「不移動直接獲勝」這個選項。

---

### 🛠️ 修復方式 (程式碼修改)
要解決這個問題,我們只需在 `runMCTS` 函數的最開頭,加入對「初始盤面連通性」的檢查。如果一開始就已經可以射殺對手,就直接回報 100% 勝率並終止搜尋。

請在您的 `runMCTS(isAuto = false)` 函數中,找到 `let rootState = { ... };` 的宣告,並在它下方加入這段檢查邏輯:

```javascript
function runMCTS(isAuto = false) {
    let rootState = {
        p0: parseInt(men_bottom[0].getAttribute("i") || men_top[0].getAttribute("i")),
        p1: parseInt(men_bottom[1].getAttribute("i") || men_top[1].getAttribute("i")),
        turn: current_man,
        empty_map: JSON.parse(JSON.stringify(empty_map)),
        arrow_map: JSON.parse(JSON.stringify(arrow_map)),
        stack_arrow: stack_arrow.slice()
    };

    // --- 新增:在展開路徑前,先檢查當前局面是否已經可以直接射殺對手 ---
    let shooter = rootState.turn === 0 ? rootState.p0 : rootState.p1;
    let target = rootState.turn === 0 ? rootState.p1 : rootState.p0;
    let canShootNow = false;
    let q = [shooter];
    let visited = new Set([shooter]);

    while (q.length > 0) {
        let curr = q.shift();
        for (let nxt of (rootState.arrow_map[curr] || [])) {
            if (nxt === target) { canShootNow = true; break; }
            if (!visited.has(nxt)) {
                visited.add(nxt);
                q.push(nxt);
            }
        }
        if (canShootNow) break;
    }

    if (canShootNow) {
        let msg = "🎯 <b>絕殺!</b><br>您現在可以直接點擊棋子射殺對手,勝率 100%!無需規劃路線。";
        let thinkingUI = document.getElementById('thinking_ui');
        let resultsUI = document.getElementById('mcts_results');
        
        if (isAuto) {
            thinkingUI.innerHTML = msg;
            thinkingUI.style.display = 'block';
            setTimeout(() => {
                thinkingUI.style.display = 'none';
                // 直接觸發棋子的點擊事件來結算遊戲
                let manDotOnClick = manOnClick.bind(men_bottom[current_man]);
                manDotOnClick(); 
            }, 1500);
        } else {
            resultsUI.innerHTML = msg;
        }
        return; // 終止後續的 MCTS 展開
    }
    // --- 新增結束 ---

    let rootMoves = getLegalMoves(rootState);
    if (rootMoves.length === 0) {
// ... 下方保留原程式碼 ...
```

加入這段程式碼後,當藍方自投羅網(走到 `8`)換綠方回合時,MCTS 就會準確識別出綠方已經處於 100% 絕殺狀態,而不會再給出 0% 的誤判。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 13:48
ejsoon
konigsberg20260411maxdepth7782

將改絕殺層數FORCE_CHECK_DEPTH

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 13:52
ejsoon
當把FORCE_CHECK_DEPTH定為超過2的數字時,它的初始運算會非常慢。

現在改為:當場上存在不多於6個橋時,FORCE_CHECK_DEPTH為2,當橋多於6但不多於12時FORCE_CHECK_DEPTH為3,當橋多於12時FORCE_CHECK_DEPTH為4。

去掉頁面上對於FORCE_CHECK_DEPTH的設置。

只需給出所要修改的地方。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 13:54
ejsoon
gemini thinking:

代码: 全选

根據您的需求,以下是針對 `FORCE_CHECK_DEPTH` 進行動態調整並移除頁面設定項的修改內容:

### 1. 修改 HTML 部分
請刪除或註解掉 `mcts_modal` 內關於「絕殺層數」的輸入框:

```html
<div class="mcts_row"><label>絕殺層數:</label> <input type="number" id="mcts_check" value="4"></div>
```

---

### 2. 修改 JavaScript 部分
您需要修改兩處將 `PARAMS.FORCE_CHECK_DEPTH` 從頁面讀取的地方,改為根據橋樑數量進行動態計算。

#### A. 修改 `displayGame` 函數中的自動下棋計時器邏輯
找到 `autoPlayTimer = setTimeout(() => { ... })` 區塊,並替換為:

```javascript
autoPlayTimer = setTimeout(() => {
    PARAMS.SIMULATIONS_PER_MOVE = parseInt(document.getElementById('mcts_sims').value) || 50;
    PARAMS.MAX_DEPTH = parseInt(document.getElementById('mcts_depth').value) || 8;
    PARAMS.MAX_PATH_LENGTH = parseInt(document.getElementById('mcts_max_path').value) || 10;
    
    // 動態計算絕殺層數
    let bridgesCount = arrows.length;
    if (bridgesCount <= 6) {
        PARAMS.FORCE_CHECK_DEPTH = 2;
    } else if (bridgesCount <= 12) {
        PARAMS.FORCE_CHECK_DEPTH = 3;
    } else {
        PARAMS.FORCE_CHECK_DEPTH = 4;
    }
    
    runMCTS(true); 
}, 500);
```

#### B. 修改 `mcts_start_btn` 的點擊事件監聽器
找到 `document.getElementById('mcts_start_btn').addEventListener('click', ...)` 區塊,並替換為:

```javascript
document.getElementById('mcts_start_btn').addEventListener('click', function() {
    // ... 前方代碼不變 ...
    PARAMS.SIMULATIONS_PER_MOVE = parseInt(document.getElementById('mcts_sims').value) || 50;
    PARAMS.MAX_DEPTH = parseInt(document.getElementById('mcts_depth').value) || 8;
    PARAMS.MAX_PATH_LENGTH = parseInt(document.getElementById('mcts_max_path').value) || 10;
    
    // 動態計算絕殺層數
    let bridgesCount = arrows.length;
    if (bridgesCount <= 6) {
        PARAMS.FORCE_CHECK_DEPTH = 2;
    } else if (bridgesCount <= 12) {
        PARAMS.FORCE_CHECK_DEPTH = 3;
    } else {
        PARAMS.FORCE_CHECK_DEPTH = 4;
    }
    
    document.getElementById('mcts_results').innerHTML = "搜尋中,請稍候...";
    setTimeout(() => runMCTS(false), 50);
});
```

這樣修改後,程式會根據場上橋樑的數量(`arrows.length`)自動調整搜尋深度,有效解決開局運算緩慢的問題,同時簡化了 UI 介面。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 14:26
ejsoon
處於這個局面:

[[3,6],[-5,3,0,1,5,9,8,4,7],[7,6,0,3,1,0,5,1,9,5,8,9,4,8,7,4],[-5,6,9,5,4,8],[7,8,0,3,1,0,5,1,5,9,8,9,8,4,7,4,9,6,4,5],[-5,7,4,0,3],[3,8,3,0,1,0,5,1,5,9,8,9,8,4,4,7,9,6,4,5,0,4]]

搜尋得到綠方如果走「8,9,6,5,1,4,3,0」的勝率是94%,然而接下來藍方只需要走「3,7,8,4,1」就可以100%獲勝。說明前面的搜尋仍然存在問題,請查找原因。

Re: 改下哥尼斯堡網頁程式

发表于 : 2026年 4月 11日 14:29
ejsoon
konigsberg20260411autoDepth7783

自動調整max depth絕殺深度。但是前面的局面仍然算不對。

https://ejsoon.vip/wp-content/uploads/2 ... h7783.html