代碼來臨 2024 年第 7 天

第 1 部分

今年第一次遞迴

至少這就是我今天想要贏得一顆金星的方式：

• 從完整清單開始
• 檢查加法和乘法
• 對於每個結(jié)果，繼續(xù)列表的其餘部分
• 直到我超過或匹配總數(shù)

困難在於細(xì)節(jié)。

讓我們開始吧！

制定我的演算法

首先，我需要將每一行解析為數(shù)字列表：

let eqs = input.split('\n').map(line => {
  return [...line.matchAll(/\d+/g)].map(el => +el[0])
})

第一個元素是所需的總數(shù)。

其餘的是方程式的有序操作數(shù)。

我需要在遞歸函數(shù)中考慮到這一點(diǎn)。

這是我的遞迴函數(shù)：

function eqChecker(operands, amount, test) {
  if (amount > test) {
    return false
  } else if (amount == test && operands.length == 0) {
    return true
  } else if (operands.length) {
    let copy = operands.slice()
    let first = copy.shift()
    return eqChecker(copy, amount + first, test) || eqChecker(copy, amount * first, test)
  }
}

這是使用它的reduce：

let part1 = eqs.reduce((count, eq) => {
  if (eqChecker(eq.slice(2), eq[1], eq[0])) {
    count += eq[0]
  }
  return count
}, 0)

正如我所希望但從未預(yù)料到的，它為範(fàn)例輸入產(chǎn)生了正確的答案！

它會完成處理我的拼圖輸入嗎？

如果是這樣，它會產(chǎn)生正確的答案嗎？

老實說我不確定......

確實如此！ ！ ！

哇！ ！ ！

儘管我很興奮，但我擔(dān)心下一部分要么會添加更多運(yùn)算符，要么需要一些高級 CS 來使遞歸不再是可行的解決方案。

第2部分

完全出乎意料！而且難度更高

我該怎麼做？

...

幾天後...

回顧一下我的思考過程：

• 就像在我的退貨條件中添加第三個條款一樣簡單嗎？ 不
• 我的第 1 部分遞歸函數(shù)是否配置正確才能成功？ 不
• 哦，不，透過先前的操作累積金額是否可行？ 不
• 我真的需要用新策略來解決這個問題嗎？ 是的

考慮所有新的變化

對於這個方程式：

292: 11 6 16 20

給定三個運(yùn)算符，這些都是可能的方程式：

11 
11+6 
11+6+16 
11+6+16+20 
11+6+16*20 
11+6+1620 
11+6*16 
11+6*16+20 
11+6*16*20 
11+6*1620 
11+616 
11*6 
11*6+16 
11*6+16+20 
11*6+16*20 
11*6+1620 
11*6*16 
11*616 
116 
116+16 
116+16+20 
116+16*20 
116+1620 
116*16 
11616 

也許我可以建立每個方程式的字串，並在遞歸函數(shù)中手動對其求值。

例如：
我在最外層函數(shù)呼叫中以空字串開始：

""

從那裡，我使用下一個數(shù)字創(chuàng)建三個變體：

"" + "+N"
"" + "*N"
"" + "N"

嗯，但這對第一個數(shù)字不起作用。

我需要用第一個數(shù)字開始我的第一個函數(shù)調(diào)用，而不是空字串：

"N"

同樣的事情：

"N" + "+N"
"N" + "*N"
"N" + "N"

是的，應(yīng)該可以。

最後，我將獲得這些範(fàn)例變體，所有這些都可以評估：

let eqs = input.split('\n').map(line => {
  return [...line.matchAll(/\d+/g)].map(el => +el[0])
})

跳至：我對其進(jìn)行了編碼...並發(fā)現(xiàn)了一個更大的問題

我寫的程式碼成功產(chǎn)生了方程式的所有變體。

function eqChecker(operands, amount, test) {
  if (amount > test) {
    return false
  } else if (amount == test && operands.length == 0) {
    return true
  } else if (operands.length) {
    let copy = operands.slice()
    let first = copy.shift()
    return eqChecker(copy, amount + first, test) || eqChecker(copy, amount * first, test)
  }
}

• i 用於沿著數(shù)字列表
• 只有當(dāng) i 位於倒數(shù)第二個索引之前或位於倒數(shù)第二個索引時，最後一個子句才會繼續(xù)

函數(shù)取得四個值：

1. 數(shù)字清單的副本，減去預(yù)期總數(shù)
2. 下一個索引
3. 由三個字串之一連接而成的方程式字串
4. 相同的測試號碼

我使用與第 1 部分幾乎相同的簽名來呼叫該函數(shù)：

let part1 = eqs.reduce((count, eq) => {
  if (eqChecker(eq.slice(2), eq[1], eq[0])) {
    count += eq[0]
  }
  return count
}, 0)

差別在於我作為參數(shù)傳遞的內(nèi)容：

1. 沒有預(yù)期總金額的清單
2. 從索引 0 開始
3. 包含第一個數(shù)字的字串
4. 預(yù)計總金額

好消息：

• 它產(chǎn)生所有方程式變化

壞消息：

• 它使用 PEMDAS 計算所有方程，而不是從左到右

我應(yīng)該更清楚...內(nèi)建的 JavaScript 求值器會預(yù)設(shè)使用正確的操作順序，而不是從左到右。

這確實給我的演算法帶來了更大的麻煩：

• 我將不得不分解每個方程式並逐個部分評估它

嗚嗚嗚。

謝天謝地，我想我知道該怎麼做。

手動做數(shù)學(xué)

我需要 JavaScript 來計算這樣的方程式：

292: 11 6 16 20

依此順序：

11 
11+6 
11+6+16 
11+6+16+20 
11+6+16*20 
11+6+1620 
11+6*16 
11+6*16+20 
11+6*16*20 
11+6*1620 
11+616 
11*6 
11*6+16 
11*6+16+20 
11*6+16*20 
11*6+1620 
11*6*16 
11*616 
116 
116+16 
116+16+20 
116+16*20 
116+1620 
116*16 
11616 

我想將方程式分成幾個部分：

""

我了解的唯一方法是使用這個三鏈表達(dá)式：

"" + "+N"
"" + "*N"
"" + "N"

我用空格填充每個運(yùn)算符，只是將其用作分隔符。

關(guān)於這個方程式部分列表的事實：

• 它將始終包含 3 個或更多的奇數(shù)項目

如何在迭代每個操作數(shù)-運(yùn)算符-操作數(shù)對的循環(huán)中利用這一事實？

這是我的想法：

• 刪除前三項
• 將它們作為字串連接，並將其作為數(shù)學(xué)表達(dá)式進(jìn)行計算
• 將結(jié)果重新附加到方程式清單的開頭
• 重複直到方程式列表為空

希望它能起作用！

我在 JavaScript 工作的數(shù)學(xué)模擬器：

"N"

好消息：

• 它向我顯示了預(yù)期的計算值

壞消息：

• 我仍然沒有得到範(fàn)例輸入中一個方程式的正確答案

範(fàn)例答案不會錯...可以嗎？

我不斷產(chǎn)生的答案比預(yù)期答案少了大約 7k。

這讓我認(rèn)為我的演算法沒有辨識出這個方程式是正確的：

let eqs = input.split('\n').map(line => {
  return [...line.matchAll(/\d+/g)].map(el => +el[0])
})

在範(fàn)例輸入的解釋中，這是獲勝方程式：

function eqChecker(operands, amount, test) {
  if (amount > test) {
    return false
  } else if (amount == test && operands.length == 0) {
    return true
  } else if (operands.length) {
    let copy = operands.slice()
    let first = copy.shift()
    return eqChecker(copy, amount + first, test) || eqChecker(copy, amount * first, test)
  }
}

我的演算法評估該方程式並產(chǎn)生以下結(jié)果：

let part1 = eqs.reduce((count, eq) => {
  if (eqChecker(eq.slice(2), eq[1], eq[0])) {
    count += eq[0]
  }
  return count
}, 0)

那是因為我的演算法是這樣運(yùn)作的：

292: 11 6 16 20

我不明白它怎麼可能是其他數(shù)字。

所以...我用谷歌搜尋了。

我找到了我的答案，它一如既往地隱藏在簡單的網(wǎng)站解釋中：

所有運(yùn)算子仍然從左到右計算。

我在每個遞歸函數(shù)呼叫中預(yù)先連接值。

相反，我的演算法應(yīng)該要這樣做：

11 
11+6 
11+6+16 
11+6+16+20 
11+6+16*20 
11+6+1620 
11+6*16 
11+6*16+20 
11+6*16*20 
11+6*1620 
11+616 
11*6 
11*6+16 
11*6+16+20 
11*6+16*20 
11*6+1620 
11*6*16 
11*616 
116 
116+16 
116+16+20 
116+16*20 
116+1620 
116*16 
11616 

現(xiàn)在我明白了應(yīng)該發(fā)生什麼，我可以調(diào)整我的演算法以匹配該處理行為嗎？

從左到右......這次是真的

值得慶幸的是，調(diào)整我的演算法相對容易。

我新增了一個replaceAll()子句來解釋||。

我處理每三個項目的新 while 迴圈如下：

""

我調(diào)整了退貨聲明的||子句包含這些字符，而不是立即連接兩個數(shù)字。

測試和重新測試

我在範(fàn)例輸入上運(yùn)行了演算法。

它終於產(chǎn)生了正確的答案！ ！

多麼輕鬆??！ ！

我想知道它是否會完成運(yùn)行並在我的拼圖輸入上產(chǎn)生正確的答案。

按運(yùn)行...

...

...

我得到答案了！

它很大，所以這可能是一個好兆頭。

這是正確答案嗎？

...

不。太高了。

真糟糕。

我錯過了一個邊緣案例嗎？

我的獲勝方程式的條件很簡單，就是處理後的數(shù)學(xué)等於測試量。

但是，如果其中一個變體方程式允許數(shù)字子集產(chǎn)生正確答案怎麼辦？

為了捕捉並排除這種情況，我更新了 if 條件以包含另一個子句：

"" + "+N"
"" + "*N"
"" + "N"

這樣，只有當(dāng)所有數(shù)字都處理完畢且結(jié)果數(shù)量等於測試數(shù)時，方程式才會被計算在內(nèi)。

大問題：

• 這會改變我得到的答案嗎？

再按下運(yùn)作...

...

嗯，看起來確實還是一樣的答案。

哦，等等，末尾附近有兩個數(shù)字不同！

我的新答案比以前少了 80。

是否有一個以 80 為預(yù)期數(shù)量的方程式？

是的！

"N"

有沒有一種方法可以在不使用所有數(shù)字的情況下得到 80？

是的！

"N" + "+N"
"N" + "*N"
"N" + "N"

這是我唯一需要排除的邊緣情況嗎？

正在提交我的新答案...

正確！ ！ ！

嗚呼！ ！ ！

我做到了！ ！ ！

那個。曾是。筋疲力盡。令人興奮。而且真的跑了。並且具有挑戰(zhàn)性。

以及我喜歡做這些謎題的所有原因。

繼續(xù)下一篇！

以上是橋樑修復(fù)的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！