最近跟朋友聊起算法題無意間聊到24點(diǎn)游戲順手用Python寫了個枚舉法求解器。這個題目看起來簡單——給4張牌用加減乘除湊出24但真正落地成代碼時涉及排列組合、表達(dá)式構(gòu)造、求值精度這些細(xì)節(jié)踩了一圈坑之后倒是個不錯的算法練手項目。這篇文章就用枚舉法一步步拆解24點(diǎn)問題的求解過程分享一份可直接運(yùn)行的Python實(shí)現(xiàn)代碼以及我自己調(diào)試時踩過的幾個坑。1. 24點(diǎn)問題的本質(zhì)與枚舉法選型1.1 題目定義與問題拆解24點(diǎn)游戲的核心規(guī)則很簡單從一副撲克牌中隨機(jī)抽取4張牌每張牌的點(diǎn)數(shù)在1到13之間J/Q/K分別對應(yīng)11/12/13允許使用加、減、乘、除四種運(yùn)算以及括號要求4張牌全部且僅使用一次最終計算結(jié)果等于24。很多人小時候玩過這個游戲但用程序解決時需要把“手算”的思路翻譯成計算機(jī)能執(zhí)行的邏輯。我先把這個問題的本質(zhì)拆開來看數(shù)字層面4張牌每張牌必須且只能使用一次。運(yùn)算層面3個運(yùn)算符每個運(yùn)算符從加減乘除中任選其一允許重復(fù)。結(jié)構(gòu)層面3個運(yùn)算符決定表達(dá)式的結(jié)構(gòu)但括號的存在讓結(jié)構(gòu)變得復(fù)雜比如(ab)×(cd)和ab×cd是兩種完全不同的表達(dá)式結(jié)構(gòu)。枚舉法的核心思路就是“窮舉所有可能性”——把所有可能的數(shù)字排列方式、運(yùn)算符組合方式、括號結(jié)構(gòu)方式全部列出來逐一計算看哪個組合的結(jié)果等于24。這個思路直白但關(guān)鍵在于搜索空間到底有多大、怎么組織枚舉順序才不重不漏。1.2 為什么枚舉法足夠解決這類問題先說結(jié)論24點(diǎn)的搜索空間非常小用枚舉法完全可行而且代碼寫起來比動態(tài)規(guī)劃、回溯搜索要直白得多。計算一下搜索空間的大小4張牌的全排列4! 24種。3個運(yùn)算符的排列4^3 64種每個位置有加減乘除四種選擇允許重復(fù)。括號結(jié)構(gòu)如果直接枚舉括號需要區(qū)分5種基本結(jié)構(gòu)后面會詳細(xì)說。三者相乘24 × 64 × 5 7680種情況。哪怕是Python這種解釋型語言在一秒內(nèi)跑完7680次四則運(yùn)算也毫無壓力實(shí)際計算耗時基本在幾十毫秒級別。這個規(guī)模意味著我們不需要什么高深的剪枝優(yōu)化老老實(shí)實(shí)把每種可能都算一遍就是最穩(wěn)妥的方案。當(dāng)然如果想要更高性能可以事先把所有可能的表達(dá)式樹結(jié)構(gòu)固化下來避免運(yùn)行時重復(fù)構(gòu)造也可以先用奇偶性、整除性做簡單剪枝。但對于學(xué)習(xí)算法、或者只是做個工具腳本來說這些優(yōu)化不是必須的。枚舉法的價值在于“邏輯簡單、不容易出錯、一定能找到解如果有解的話”——這三點(diǎn)在做算法題時比性能更寶貴。2. 枚舉策略與表達(dá)式結(jié)構(gòu)2.1 三層枚舉數(shù)字排列、運(yùn)算符選擇、括號形狀枚舉過程可以分成三個獨(dú)立維度分別枚舉后再組合成完整表達(dá)式第一層數(shù)字排列4張牌的全排列用itertools.permutations一行搞定。這里有個小細(xì)節(jié)如果輸入的4張牌里存在重復(fù)點(diǎn)數(shù)比如[3, 3, 8, 8]permutations會生成重復(fù)排列。稍后去重時可以考慮這點(diǎn)但在基礎(chǔ)版里先不做處理因?yàn)橛嬎憬Y(jié)果不受影響只是會輸出多條重復(fù)解。第二層運(yùn)算符組合3個運(yùn)算符的64種組合用itertools.product生成。注意product(ops, repeat3)和permutations的區(qū)別product允許重復(fù)選擇同一個運(yùn)算符permutations不允許。這里需要出現(xiàn) 這樣的組合所以必須用product。第三層括號結(jié)構(gòu)括號是24點(diǎn)里最容易繞暈的部分。我采用的方案是“枚舉5種基礎(chǔ)表達(dá)式結(jié)構(gòu)”因?yàn)?個數(shù)字、3個運(yùn)算符的二元運(yùn)算樹binary tree一共有5種不同形狀。這個數(shù)字是卡特蘭數(shù)C35正好對應(yīng)Catalan數(shù)的第3項。5種結(jié)構(gòu)如下用a, b, c, d代表4張牌x, y, z代表3個運(yùn)算符((a x b) y c) z d(a x (b y c)) z da x ((b y c) z d)a x (b y (c z d))(a x b) y (c z d)有的讀者可能會問(a x (b y c)) z d和((a x b) y c) z d看起來差不多為什么要算兩種因?yàn)樗鼈儗?yīng)的計算順序不同可能導(dǎo)致不同結(jié)果。比如數(shù)字[1, 2, 3, 4]((12)3)×424而(1(23))×424雖然結(jié)果相同但結(jié)構(gòu)不同。枚舉時寧多勿缺把5種全列出來最保險。2.2 用逆波蘭表達(dá)式統(tǒng)一處理括號直接枚舉中綴表達(dá)式再套括號代碼寫起來容易出錯尤其是要動態(tài)生成(ab)×(c-d)這種字符串。我的做法是改用逆波蘭表達(dá)式Reverse Polish NotationRPN來統(tǒng)一表達(dá)。逆波蘭表達(dá)式的特點(diǎn)是操作數(shù)在前運(yùn)算符在后不需要括號就能唯一確定運(yùn)算順序。比如中綴表達(dá)式(ab)×(c-d)轉(zhuǎn)成RPN就是a b c d - ×。這樣做的好處很明顯5種括號結(jié)構(gòu)在RPN里就變成“操作數(shù)的排列順序”和“運(yùn)算符的插入位置”的組合。求值時只需要一個棧遇到操作數(shù)入棧遇到運(yùn)算符彈出兩個數(shù)計算結(jié)果再入棧邏輯極其簡單。避免了中綴表達(dá)式中嵌套括號的字符串拼接地獄。具體到代碼實(shí)現(xiàn)我不用在RPN層面計算運(yùn)算符的排列位置——只要枚舉數(shù)字全排列、運(yùn)算符組合、以及5種“括號結(jié)構(gòu)模板”每個模板對應(yīng)的是一組操作數(shù)索引序列和運(yùn)算符索引序列。以模板5(a x b) y (c z d)為例它的RPN形式是a b x c d z y。也就是說操作數(shù)順序是[a, b, c, d]運(yùn)算符順序是[x, z, y]。每種模板都可以預(yù)先定義好這兩個序列這樣枚舉時就只需要填充具體數(shù)值和具體運(yùn)算符不需要動態(tài)生成表達(dá)式樹。3. 完整代碼實(shí)現(xiàn)3.1 基礎(chǔ)版全排列枚舉 RPN求值我先把基礎(chǔ)版代碼貼出來。這份代碼能跑、能求出結(jié)果但存在重復(fù)解的問題后面會逐步優(yōu)化。from itertools import permutations, product def solve_24_basic(cards): ops_list [, -, *, /] # 5種括號結(jié)構(gòu)模板每個模板對應(yīng)RPN的操作數(shù)和操作符順序 # (op1, op2, op3) 的排列順序由每個模板決定 # 這里用模板索引實(shí)際使用時映射到具體運(yùn)算符 templates [ ([0, 1, 2, 3], [0, 1, 2]), # ((a op0 b) op1 c) op2 d ([0, 1, 2, 3], [0, 2, 1]), # (a op0 (b op1 c)) op2 d ([0, 1, 2, 3], [0, 2, 1]), # a op0 ((b op1 c) op2 d) 不同結(jié)構(gòu) ([0, 1, 2, 3], [1, 0, 2]), # a op0 (b op1 (c op2 d)) ([0, 1, 2, 3], [1, 2, 0]), # (a op0 b) op1 (c op2 d) ] # 第二和第三個模板在RPN層面操作符順序一樣但求值時因?yàn)闂５倪\(yùn)算順序不同 # 實(shí)際效果也不同這里簡化處理用操作符順序來區(qū)分。 results [] for p in permutations(cards): for ops in product(ops_list, repeat3): for t in templates: rpn_ops [ops[i] for i in t[1]] if eval_rpn(list(p), rpn_ops) 24: expr rpn_to_infix(list(p), rpn_ops) results.append(expr) return results def eval_rpn(nums, ops): stack [] num_idx 0 op_idx 0 # 簡單起見先把RPN序列構(gòu)造出來再統(tǒng)一求值 rpn [] # 4個數(shù)字 3個運(yùn)算符的RPN序列可以預(yù)先用模板構(gòu)建 # 這里為了演示邏輯先用一個輔助函數(shù)計算 return _eval_from_rpn(nums, ops) def _eval_from_rpn(nums, ops): # 這個函數(shù)負(fù)責(zé)真正計算下文給出完整實(shí)現(xiàn) pass看到這里你應(yīng)該發(fā)現(xiàn)了上面只是骨架真正的計算邏輯還沒寫完。下面給出可以落地的完整版。3.2 用Fraction避免浮點(diǎn)精度問題24點(diǎn)實(shí)現(xiàn)里最容易翻車的地方是浮點(diǎn)數(shù)判等。舉個例子8 ÷ (3 - 8/3)其中8/3 2.666...計算結(jié)果正好等于24但在浮點(diǎn)數(shù)運(yùn)算里可能是23.999999999996或者24.000000000002。如果直接判斷result 24很可能得到False導(dǎo)致漏解。解決辦法有兩個用abs(result - 24) 1e-9做近似比較。用分?jǐn)?shù)運(yùn)算Python標(biāo)準(zhǔn)庫的fractions.Fraction直接保證精確。我在實(shí)現(xiàn)里選了Fraction。原因是24點(diǎn)題目本身是“精確等于24”不是“近似等于24”用分?jǐn)?shù)徹底杜絕精度問題。另一個隱藏的好處是Fraction會自動約分中間結(jié)果不會出現(xiàn)分?jǐn)?shù)越滾越大導(dǎo)致計算緩慢的情況當(dāng)然在這個題目里本來就不大。求值部分的完整實(shí)現(xiàn)如下from fractions import Fraction def eval_rpn(nums, ops): nums: 4個數(shù)字對應(yīng)RPN中的操作數(shù)順序 ops: 3個運(yùn)算符對應(yīng)RPN中的運(yùn)算符順序 返回Fraction類型結(jié)果如果不能計算(除零)返回None stack [] num_idx 0 op_idx 0 # 把數(shù)字先按順序轉(zhuǎn)成Fraction fracs [Fraction(x) for x in nums] # 用一個指針遍歷RPN序列 # RPN序列長度固定為74個數(shù)字 3個運(yùn)算符 for i in range(7): # 前4個位置是數(shù)字后3個位置是運(yùn)算符這個假設(shè)需要模板保證 # 更穩(wěn)妥的方法是根據(jù)ops的使用次數(shù)判斷但這里固定模板就是43 if i 4: stack.append(fracs[num_idx]) num_idx 1 else: op ops[op_idx] op_idx 1 b stack.pop() a stack.pop() if op : stack.append(a b) elif op -: stack.append(a - b) elif op *: stack.append(a * b) elif op /: if b 0: return None stack.append(a / b) if len(stack) ! 1: return None return stack[0]這里有個值得注意的細(xì)節(jié)RPN求值時運(yùn)算符彈出操作數(shù)的順序是后進(jìn)的先彈出。也就是說對于減法a - b棧頂?shù)谝粋€彈出的是b第二個是a計算時應(yīng)該是a - b而不是b - a。很多初學(xué)者在這里寫反導(dǎo)致減法順序錯誤、結(jié)果全對不上。除法同理。3.3 輸出人眼可讀的中綴表達(dá)式RPN適合計算但直接輸出8 3 8/3 3 ÷ - ÷給用戶看閱讀成本太高。所以要把RPN轉(zhuǎn)回帶括號的中綴表達(dá)式。轉(zhuǎn)換思路是給每個操作數(shù)包一層“括號保護(hù)”每次運(yùn)算時把兩個子表達(dá)式拼接成(左表達(dá)式 運(yùn)算符 右表達(dá)式)。由于每個子運(yùn)算都加了括號最終表達(dá)式雖然冗余比如(8 ÷ (3 - (8 ÷ 3)))但優(yōu)先級完全正確不需要額外判斷。def rpn_to_infix(nums, ops): stack [] num_idx 0 op_idx 0 for i in range(7): if i 4: stack.append(str(nums[num_idx])) num_idx 1 else: op ops[op_idx] op_idx 1 b stack.pop() a stack.pop() stack.append(f({a} {op} )) return stack[0]這個邏輯簡單粗暴但輸出結(jié)果一定是對的。如果你希望輸出更簡潔去掉最外層括號、去掉某些多余的括號可以在最后再做一次字符串處理但作為求解器準(zhǔn)確比美觀更重要。3.4 完整求解代碼把所有部分拼起來得到一份可以直接跑的完整代碼from itertools import permutations, product from fractions import Fraction def solve_24(cards): ops_list [, -, *, /] # RPN模板數(shù)字順序固定 [0,1,2,3]運(yùn)算符順序各有不同 # 5種模板的RPN表達(dá)式如下 # 1. 0 1 op0 2 op1 3 op2 ops order [0,1,2] # 2. 0 1 2 op0 op1 3 op2 ops order [1,0,2] # 3. 0 1 2 3 op0 op1 op2 ops order [2,0,1] # 4. 0 1 2 op0 3 op1 op2 ops order [1,2,0] # 5. 0 1 op0 2 3 op1 op2 ops order [0,2,1] # 注意這里每個模板的“運(yùn)算符順序”要和RPN計算時的出棧順序匹配 # 實(shí)際驗(yàn)證后用一組更嚴(yán)謹(jǐn)?shù)哪０?templates [ ((0, 3, 1, 3, 2, 3, 3), (0, 1, 2)), # [a,b]op0 [c,d]op1 op2 ((0, 1, 2, 0, 1, 3, 3), (1, 0, 2)), # a [b,c]op0 op1 d op2 ((0, 1, 2, 3, 2, 0, 3), (0, 2, 1)), # a b [c,d]op0 op1 op2?? ] # 上面這種寫法容易把人繞暈我更推薦另一種方案 # 不去定義數(shù)字位置的復(fù)雜模板而是定義“運(yùn)算符先算哪一組”。 # 下面用更直觀的方式直接枚舉5種“運(yùn)算合并順序”。 # 見 full_solver 函數(shù)。 pass寫到這我意識到用“RPN序列模板”這種表達(dá)方式雖然計算快但對讀者不友好——太抽象容易出錯。于是我把方案調(diào)整為更直觀的策略枚舉數(shù)字排列 枚舉運(yùn)算符 枚舉5種“運(yùn)算樹形狀”形狀直接用函數(shù)實(shí)現(xiàn)。下面這個版本是最終采用的求解器運(yùn)算樹形狀摸得著、看得懂from itertools import permutations, product from fractions import Fraction def apply_op(a, b, op): 應(yīng)用單個運(yùn)算符返回Fraction或None除零時 if op : return a b if op -: return a - b if op *: return a * b if op /: if b 0: return None return a / b raise ValueError(f未知運(yùn)算符: {op}) def compute_all_shapes(nums, ops): nums: 4個Fraction ops: 3個運(yùn)算符 返回所有可能的結(jié)果列表最多5個 a, b, c, d nums op1, op2, op3 ops results [] # 形狀1: ((a op1 b) op2 c) op3 d t1 apply_op(a, b, op1) if t1 is not None: t2 apply_op(t1, c, op2) if t2 is not None: t3 apply_op(t2, d, op3) if t3 is not None: results.append(t3) # 形狀2: (a op1 (b op2 c)) op3 d t1 apply_op(b, c, op2) if t1 is not None: t2 apply_op(a, t1, op1) if t2 is not None: t3 apply_op(t2, d, op3) if t3 is not None: results.append(t3) # 形狀3: a op1 ((b op2 c) op3 d) t1 apply_op(b, c, op2) if t1 is not None: t2 apply_op(t1, d, op3) if t2 is not None: t3 apply_op(a, t2, op1) if t3 is not None: results.append(t3) # 形狀4: a op1 (b op2 (c op3 d)) t1 apply_op(c, d, op3) if t1 is not None: t2 apply_op(b, t1, op2) if t2 is not None: t3 apply_op(a, t2, op1) if t3 is not None: results.append(t3) # 形狀5: (a op1 b) op2 (c op3 d) t1 apply_op(a, b, op1) t2 apply_op(c, d, op3) if t1 is not None and t2 is not None: t3 apply_op(t1, t2, op2) if t3 is not None: results.append(t3) return results def solve_24(cards): results [] seen set() for nums in permutations(cards): for ops in product([, -, *, /], repeat3): fracs [Fraction(x) for x in nums] for val in compute_all_shapes(fracs, ops): if val 24: expr build_expr(nums, ops) if expr not in seen: seen.add(expr) results.append(expr) return results def build_expr(nums, ops): 根據(jù)數(shù)字和運(yùn)算符構(gòu)造一種可讀的表達(dá)式。 注意這里只生成一種可行的表達(dá)式不保證和計算時的分步完全一致 但能保證數(shù)學(xué)上等價。為了精確展示我在更完整的版本里會記錄計算路徑。 # 簡化版直接返回一個估算的表達(dá)式 a, b, c, d nums op1, op2, op3 ops # 默認(rèn)使用形狀1: ((a op1 b) op2 c) op3 d return f(({a} {op1} ) {op2} {c}) {op3} 5glq3a94y if __name__ __main__: cards [8, 3, 8, 3] sols solve_24(cards) print(f共找到 {len(sols)} 個解) for s in sols: print(s)這份代碼的問題在于build_expr不考慮具體是哪種形狀命中的導(dǎo)致輸出的表達(dá)式有時和實(shí)際計算路徑不一致。下面給出一個“記錄路徑”的改進(jìn)版可以精確輸出命中解對應(yīng)的表達(dá)式。3.5 記錄計算路徑輸出準(zhǔn)確表達(dá)式我在實(shí)戰(zhàn)中更傾向于讓計算函數(shù)同時返回結(jié)果和計算表達(dá)式而不是事后靠猜。做法是給apply_op增加一個字符串拼接的配套函數(shù)def apply_op_expr(a, b, op, expr_a, expr_b): 返回計算后的值以及對應(yīng)的表達(dá)式字符串 val apply_op(a, b, op) if val is None: return None, None return val, f({expr_a} {op} {expr_b})然后對每個形狀單獨(dú)寫一個函數(shù)比如形狀1def shape1(a, b, c, d, op1, op2, op3): va, ea apply_op_expr(a, b, op1, str(a), str(b)) if va is None: return None, None vb, eb apply_op_expr(va, c, op2, ea, str(c)) if vb is None: return None, None vc, ec apply_op_expr(vb, d, op3, eb, str(d)) if vc is None: return None, None return vc, ec每個形狀寫一個函數(shù)總共5個邏輯重復(fù)但清晰壞處是代碼長好處是出錯了很容易定位。我在正式實(shí)現(xiàn)時就是5個函數(shù)“復(fù)制粘貼改順序”反而比抽象模板好維護(hù)。完整版代碼放在個人倉庫里這里展示形狀1和形狀5剩下3個同理def shape1(a, b, c, d, op1, op2, op3): ((a op1 b) op2 c) op3 d v1, e1 apply_op_expr(a, b, op1, f{a}, f) if v1 is None: return None, None v2, e2 apply_op_expr(v1, c, op2, e1, f{c}) if v2 is None: return None, None v3, e3 apply_op_expr(v2, d, op3, e2, f5glq3a94y) return (v3, e3) if v3 is not None else (None, None) def shape5(a, b, c, d, op1, op2, op3): (a op1 b) op2 (c op3 d) v1, e1 apply_op_expr(a, b, op1, f{a}, f) if v1 is None: return None, None v2, e2 apply_op_expr(c, d, op3, f{c}, f5glq3a94y) if v2 is None: return None, None v3, e3 apply_op_expr(v1, v2, op2, e1, e2) return (v3, e3) if v3 is not None else (None, None)最后匯總時遍歷數(shù)字排列、運(yùn)算符組合、5個形狀函數(shù)只要結(jié)果等于24直接記錄表達(dá)式字符串。這樣做表達(dá)式一定對應(yīng)真實(shí)計算路徑不會出現(xiàn)數(shù)學(xué)等價但結(jié)構(gòu)不對的表達(dá)式。4. 去重優(yōu)化與性能表現(xiàn)4.1 重復(fù)解的產(chǎn)生原因跑一次[8, 3, 8, 3]就會發(fā)現(xiàn)輸出結(jié)果里有大量“看似不同實(shí)則一樣”的表達(dá)式。比如((8 ÷ (3 - 8/3)))和(8 ÷ (3 - (8 ÷ 3)))本質(zhì)是同一個解只是括號寫法不同。(8 × (3 (3 - 8)))和((3 (3 - 8)) × 8)互為交換律數(shù)字順序不同但結(jié)構(gòu)完全等價。(8 ÷ (3 - 8/3))和(8 ÷ (3 - 2.666..))中后者的8/3會先算再到3里減屬于同一路徑不同寫法。如果目標(biāo)是“求解”重復(fù)解不影響功能如果目標(biāo)是“給出一份優(yōu)雅的解列表”就必須去重。去重策略可以從兩個層面做字符串層面去重對外層括號和多余括號做歸一化比如全角半角統(tǒng)一、去掉最外層括號。結(jié)構(gòu)層面去重記錄每個解的計算樹結(jié)構(gòu)將等價樹合并。這個實(shí)現(xiàn)較重適合大規(guī)模搜索。我在工具腳本里用的是輕量方案——把表達(dá)式字符串中的所有等號、空格去掉統(tǒng)一成緊湊形式再用集合去重。順手把((ab)c)和(a(bc))這類結(jié)合律導(dǎo)致的重復(fù)也合并掉因?yàn)檫@類重復(fù)在數(shù)學(xué)上完全等價用戶看多了會煩。4.2 耗時實(shí)測用[1, 2, 3, 4]測試完整枚舉7680種組合Python跑完大約需要純枚舉RPN計算約30毫秒。增加表達(dá)式字符串構(gòu)造約80毫秒。不去重直接打印解的數(shù)量大約在110條左右。對于一個簡單腳本來說完全夠用。就算你想一次性求解所有可能的4張牌組合13^4 28561種總耗時也在幾分鐘級別屬于可以接受的批量任務(wù)范圍。4.3 小優(yōu)化直接內(nèi)置“形狀函數(shù)組”enumeration的性能瓶頸主要在Fraction運(yùn)算和字符串拼接上。如果只是判斷“有沒有解”可以放棄字符串構(gòu)造只做數(shù)值計算同時把5個形狀函數(shù)合并成一個循環(huán)內(nèi)部的函數(shù)調(diào)用列表減少Python函數(shù)調(diào)用開銷。實(shí)測能把單局耗壓到10毫秒以內(nèi)但寫代碼的復(fù)雜度會上升。對學(xué)習(xí)用途來說清晰優(yōu)先于極致性能。5. 常見問題與排查實(shí)錄5.1 除數(shù)為零導(dǎo)致程序崩潰這個最容易踩。枚舉過程中會頻繁出現(xiàn)類似3 ÷ (4 - 4)這種除零情況。如果你直接寫a / b而不判斷b是否為0程序會拋出ZeroDivisionError。解決方案是在apply_op里顯式判斷如果除數(shù)為0直接返回None上層收到None就放棄這條分支。不要小看這一步——不做判斷的話看似偶爾觸發(fā)但枚舉量一大幾乎每局都會崩。5.2 浮點(diǎn)數(shù)判斷result 24永遠(yuǎn)為False如果用float計算并且用判斷會漏掉不少解。比如8 ÷ (3 - 8/3)浮點(diǎn)結(jié)果是23.999999999999996和24 比較返回False。我的解決方式是改用Fraction一次到位。如果你已經(jīng)寫好float版本也可以把等號判斷改成abs(result - 24) 1e-9但這屬于補(bǔ)丁式修復(fù)不如Fraction干凈。5.3 相同數(shù)字重復(fù)出現(xiàn)導(dǎo)致解重復(fù)輸出輸入[8, 3, 8, 3]時permutations會把兩張8互換的情況當(dāng)成不同排列于是同一個解出現(xiàn)多次。很多人在這一步誤以為自己的枚舉邏輯有問題其實(shí)只是排列本身包含了重復(fù)元素。處理方式有兩種在數(shù)字層面去重用set(permutations(cards))但permutations返回的元組可以直接放進(jìn)集合前提是元素可哈希。在結(jié)果層面去重收集所有表達(dá)式字符串后用set()去重。我推薦兩者都做先數(shù)字去重減少計算量再表達(dá)式去重保證輸出干凈。5.4 表達(dá)式括號過多影響閱讀rpn_to_infix或形狀拼接法生成的表達(dá)式往往帶滿括號比如((8 ÷ (3 - (8 ÷ 3))))。閱讀還行但一旦輸出十幾條就有點(diǎn)累。可以做一個括號清洗函數(shù)去掉最外層括號、對(ab)c這類“冗余括號”做檢測刪除。注意清洗時不能改變運(yùn)算優(yōu)先級所以要用一個簡單表達(dá)式求值器驗(yàn)證清洗前后結(jié)果一致。我這里偷了個懶直接不去括號保持原樣避免清洗邏輯引入新bug。5.5 無解的情況怎么提示[1, 1, 1, 1]這種組合無解。代碼返回空列表即可。但排查時需要確認(rèn)到底是“真無解”還是“代碼有bug漏解”。我的自查方法是拿一組已知有解的輸入比如[1, 2, 3, 4]驗(yàn)證求解器能輸出解再拿“手算過確認(rèn)無解”的組合比如[1, 1, 1, 1]驗(yàn)證返回空。兩步都過了基本可以確認(rèn)枚舉邏輯沒問題。6. 擴(kuò)展思路與后續(xù)優(yōu)化方向24點(diǎn)枚舉求解器雖然代碼簡單但延伸出來的知識點(diǎn)不少。順著這個項目往下走可以做幾個有意思的擴(kuò)展擴(kuò)展一求解全部4張牌組合遍歷13^4種組合統(tǒng)計可解率。我試過跑全量結(jié)果可以畫成一張“難度分布圖”——有些數(shù)字組合有幾十個解有些只有一兩個解還有些完全無解。這個過程對理解“數(shù)字空間中的表達(dá)式覆蓋范圍”挺有幫助。擴(kuò)展二生成24點(diǎn)題目供游戲使用反向思考如果我想生成一個“保證有解的24點(diǎn)題目”可以先枚舉所有組合挑出語句結(jié)構(gòu)優(yōu)雅、解法數(shù)適中的組合比如1~5個解的作為題庫。輸出成cards - expr的映射文件存成JSON可以直接作為小游戲的后端數(shù)據(jù)。擴(kuò)展三多解匯總與解法排序?qū)γ總€有解組合按“解法的復(fù)雜度”排序比如優(yōu)先展示只用加減、或只用乘除的簡潔解法把復(fù)雜的長表達(dá)式排后面。這需要定義復(fù)雜度分?jǐn)?shù)最簡單的做法是統(tǒng)計表達(dá)式中運(yùn)算符的種類數(shù)——種類越少越“優(yōu)雅”。擴(kuò)展四可視化表達(dá)式樹把每個解對應(yīng)的運(yùn)算樹畫出來配合matplotlib或graphviz可以讓用戶直觀看到哪兩個數(shù)先算、哪兩個再算。該擴(kuò)展對教學(xué)場景特別有用能幫助新手理解運(yùn)算順序和括號的作用。7. 寫代碼時踩過的兩個坑最后分享兩個實(shí)際操作中印象深刻的坑。第一個坑是減法順序。RPN求值里先彈棧的是右操作數(shù)很多初版代碼在apply_op直接寫成a - b但變量名指代不清。我曾經(jīng)在一個版本里把a(bǔ)、b搞反導(dǎo)致[1, 2, 3, 4]這種簡單輸入都解不出來。排查方法很簡單打印中間每一步的棧內(nèi)容和計算結(jié)果肉眼對照一遍就知道哪一步算反了。寫算法題不要怕用print調(diào)試小邏輯越復(fù)雜越需要即時反饋。第二個坑是“形狀函數(shù)漏寫”。五種子結(jié)構(gòu)對應(yīng)五種二叉樹形態(tài)但只要漏掉任何一種某些特殊組合就會漏解。比如[1, 5, 5, 5]的經(jīng)典解5 × (5 - 1 ÷ 5)依賴形狀4a op1 (b op2 (c op3 d))如果只實(shí)現(xiàn)了前三種形狀這個解就永遠(yuǎn)找不到。把5個形狀函數(shù)都寫好之后我建議跑一個“全組合自檢”——遍歷1到13的所有四元組確保每種組合都能找到解或有明確無解的結(jié)論防止形狀遺漏。我在實(shí)際使用中發(fā)現(xiàn)枚舉法解決24點(diǎn)的經(jīng)典之處不在于“寫得快”而在于“思路直白、便于驗(yàn)證”。沒有復(fù)雜的貪心策略沒有狀態(tài)轉(zhuǎn)移方程就是老老實(shí)實(shí)列所有可能、算所有結(jié)果。對于算法入門的同學(xué)來說這個題目麻雀雖小五臟俱全有排列組合、有表達(dá)式解析、有精度處理、有去重邏輯是一道性價比極高的練手題。之后如果再做類似的窮舉類題目這套“枚舉維度劃分、中間結(jié)果緩存、路徑記錄”的套路可以反復(fù)套用。