本文详解重言式判别算法的完整实现流程，涵盖词法扫描、中缀转后缀（调度场算法）、表达式树构建、真值枚举与剪枝优化。重点包括短路求值、三值逻辑部分赋值剪枝、变量掩码枚举及反例输出机制，并强调运算符优先级约定、一元非处理、递归深度控制等关键实现细节，适用于数据结构与算法课程设计。
简介：这是一份面向计算机科学与技术专业学生的《数据结构与算法》课程设计报告，主题为重言式判别程序的设计与实现，适合正在学习栈、二叉树与表达式求值的本科阶段读者参考。报告覆盖题目要求、问题分析、数据结构选择、概要设计与测试用例等内容，重点讲解如何通过真值表判别逻辑表达式为重言式、矛盾式或可满足式，并运用两个堆栈与二叉树处理运算符优先级及表达式求值。资源仅含1个doc文档，压缩包大小约293KB，内容结构清晰，便于直接开展原理研读与编码对照。已有147人学习下载，适合作为课程设计写作框架、算法思路梳理及代码调试的参考资料，尤其对需完成类似题目或复习算符优先分析、中序遍历求值的读者较有实用价值。
1. 重言式判别是什么：一道课程设计题背后的三块硬功夫
“重言式判别”这几个字，看起来像是离生产很远的名词题，实际是数据结构与算法课程设计里少有的能把栈、二叉树、复杂度全串起来的题目：给定一个只含命题变量和逻辑运算符的公式，判断它对所有真值赋值是否恒真。真正动手的人很快会发现，卡人的不是“枚举所有取值”这个朴素想法，而是词法怎么拆、优先级怎么定、一元非怎么处理、2 的 n 次方组合怎么剪枝。这篇文章把整套判别流程拆开讲，附可复现代码和边界参数，适合正在写课程设计报告的学生，也适合想复习“栈 + 树”组合拳的从业者。
2. 把公式变成机器能算的结构：词法拆分、中缀转后缀与表达式树
2.1 先约定运算符与优先级：这份表定了，后面少吵三天
重言式判别第一步不是写代码，是定“公式语言”的语法。常见的输入是一串字符串，比如 p & !q | r ，里面有小写字母变量、括号和逻辑运算符。不同教材对蕴含、等价的优先级定义并不统一，如果不在一开始约定清楚，后面调试翻车时你根本分不清是解析错还是判别错。
我一般直接沿用课程设计题里最常见的约定：变量只允许小写字母 a~z ；一元运算符是 ! （非）；二元运算符是 & （与）、 | （或）、 > （蕴含）、 ~ （等价/双条件）。优先级从高到低是 ! 、 & 、 | 、 > 和 ~ ， > 与 ~ 同级且左结合。
| 运算符 | 含义 | 结合性 | 优先级 |
|---|---|---|---|
! | 非 | 右结合 | 4 |
& | 与 | 左结合 | 3 |
| ` | ` | 或 | 左结合 |
> | 蕴含 | 左结合 | 1 |
~ | 等价 | 左结合 | 1 |
这个优先级表直接对应 C++ 里的一个函数：
int priority(char c) {
switch (c) {
case '!': return 4;
case '&': return 3;
case '|': return 2;
case '>': return 1;
case '~': return 1;
default: return 0; // '(' 或任意非法字符
}
}
这段代码没有任何技巧，但它写完后整篇代码的“语法事实”就被锁死了。 > 和 ~ 同级左结合意味着 a > b ~ c 会被解析成 (a > b) ~ c ，而不是 a > (b ~ c) 。课程设计报告里一定要把这张表原样放进去，答辩时老师最常问的就是“你的优先级怎么定义的”。
2.2 词法扫描：不把括号和变量切开，后面全是玄学
词法扫描就是从头到尾把字符串切成 token 列表。每个 token 要么是一个变量字母，要么是一个运算符字符，要么是一个括号字符。这一步如果漏掉非法字符检查，后面所有报错都会变得莫名其妙，让你误以为是“重言式判别算法有问题”。
vector<string> tokenize(const string& s) {
vector<string> tokens;
for (int i = 0; i < (int)s.size();) {
if (isspace(s[i])) { ++i; continue; }
if (isalpha(s[i])
|| s[i] == '(' || s[i] == ')'
|| s[i] == '!' || s[i] == '&'
|| s[i] == '|' || s[i] == '>' || s[i] == '~') {
tokens.push_back(string(1, s[i]));
++i;
} else {
throw runtime_error(string("非法字符: ") + s[i]);
}
}
return tokens;
}
isspace 会跳过空格和换行，所以输入里可以自由加空格，比如 p & !q 和 p&!q 等价。单字符 token 的约定简化了后续所有处理，代价是不支持 abc 这种多字符变量名，课程设计里完全够用。
词法只负责切分，语法模式校验还要再看一遍 token 序列。最常见的非法输入是缺运算符，比如 a(b|c) 或 a b ：
void validateTokens(const vector<string>& tokens) {
for (int i = 1; i < (int)tokens.size(); ++i) {
bool preCanEnd = isalpha(tokens[i-1][0]) || tokens[i-1] == ")";
bool curCanStart = isalpha(tokens[i][0]) || tokens[i] == "(";
if (preCanEnd && curCanStart)
throw runtime_error("缺少运算符: " + tokens[i-1] + " 和 " + tokens[i] + " 之间");
}
}
这个校验的含义是：一个能结束表达式片段的 token（变量或右括号）后面只能跟运算符或右括号；一个能开始表达式片段的 token（变量或左括号）前面只能跟运算符或左括号。两条规则合起来能挡住大部分低级错误。
2.3 中缀转后缀：用栈把人的读法和机器的读法对齐
中缀公式直接建树也可以，但要做优先级判断，很容易写出 bug。我习惯先用经典的调度场算法把中缀转成后缀（逆波兰），再从中缀的后缀序列建树。后缀序列的好处是建树过程完全线性，不需要回头看优先级。
vector<string> infixToPostfix(const vector<string>& tokens) {
vector<string> out;
vector<string> st;
for (const string& t : tokens) {
if (t == "(") {
st.push_back(t);
} else if (t == ")") {
while (!st.empty() && st.back() != "(") {
out.push_back(st.back());
st.pop_back();
}
if (st.empty()) throw runtime_error("右括号不匹配");
st.pop_back(); // 弹出 '('
} else if (t == "!" || t == "&" || t == "|" || t == ">" || t == "~") {
while (!st.empty() && st.back() != "("
&& priority(st.back()[0]) >= priority(t[0])) {
out.push_back(st.back());
st.pop_back();
}
st.push_back(t);
} else if (isalpha(t[0])) {
out.push_back(t);
}
}
while (!st.empty()) {
if (st.back() == "(") throw runtime_error("左括号不匹配");
out.push_back(st.back());
st.pop_back();
}
return out;
}
弹栈条件用 >= ，这对左结合的二元运算符是对的：碰到同级运算符时，先让栈里那个同级的出去，保证从左到右结合。 ! 在这个约定下优先级最高，所以它压栈后遇到后面的二元运算符不会立刻被弹出来，只有遇到右括号或表达式结束才出栈。比如 !a & b 转后缀是 a ! b & ，对应 (!a) & b ； a & !b 转后缀是 a b ! & ，对应 a & (!b) 。
举个例子，输入 p & !q | r ，转后缀的过程是： p 直接输出， & 压栈， ! 压栈， q 输出，遇到 | 时栈顶 ! 优先级高于 | ，先把 ! 弹出来， & 优先级高于 | 所以留在栈里，然后 | 压栈， r 输出，最后把栈里的 & 、 | 依次弹出。最终后缀是 p q ! & r | 。
2.4 后缀表达式建树：一棵二叉树承载全部求值
拿到后缀序列后，用另一个栈建表达式树。节点结构很简单：变量是叶子节点，运算符是内部节点，一元 ! 只挂左子树，二元运算符挂左右子树。
struct Node {
char op; // 'a'~'z' 表示变量，'!' '&' '|' '>' '~' 表示运算符
Node* left;
Node* right;
Node(char c) : op(c), left(nullptr), right(nullptr) {}
};
Node* buildTree(const vector<string>& postfix) {
vector<Node*> st;
for (const string& t : postfix) {
if (t == "!") {
if (st.empty()) throw runtime_error("表达式不完整");
Node* x = st.back(); st.pop_back();
Node* n = new Node('!');
n->left = x;
st.push_back(n);
} else if (t == "&" || t == "|" || t == ">" || t == "~") {
if (st.size() < 2) throw runtime_error("二元运算符缺少操作数");
Node* r = st.back(); st.pop_back();
Node* l = st.back(); st.pop_back();
Node* n = new Node(t[0]);
n->left = l;
n->right = r;
st.push_back(n);
} else if (isalpha(t[0])) {
st.push_back(new Node(t[0]));
}
}
if (st.size() != 1) throw runtime_error("表达式栈遗留节点");
return st.back();
}
建树过程的每个分支都做了栈空检查，这是血泪经验：后缀序列来自中缀转后缀，只要转的过程正确，这里理论上不会出错，但防御性检查能帮你快速定位“中缀转后缀写错了”还是“输入本身就非法”。另外， new 出来的节点在程序退出前要释放，按后序遍历依次 delete 即可，课程设计报告里写一句“采用后序递归释放”就够，代码这里不展开。
到这里，公式已经从字符串变成了一棵表达式树。下一步就是对这棵树做真值赋值枚举，判断它是否为重言式。
3. 从暴力枚举到剪枝算法：判别主流程的三次提速
3.1 收集变量并按掩码枚举：暴力枚举算法的第一版
表达式树建好后，第一件事是收集公式里出现过的所有变量。因为后面要对每个变量都试 true/false 两种取值，组合数是 2 的变量数次方，变量收集只能做一次，不能在循环里重复扫描。
vector<char> collectVars(Node* root) {
vector<char> vars;
int seen[26] = {0};
vector<Node*> stack;
stack.push_back(root);
while (!stack.empty()) {
Node* n = stack.back();
stack.pop_back();
if (isalpha(n->op)) {
if (!seen[n->op - 'a']) {
seen[n->op - 'a'] = 1;
vars.push_back(n->op);
}
} else {
if (n->left) stack.push_back(n->left);
if (n->right) stack.push_back(n->right);
}
}
return vars;
}
这里用 seen[26] 做去重，变量顺序按第一次出现的顺序记录。这个顺序很重要，因为后面枚举掩码时，第 i 位固定对应 vars[i] ，输出反例时才能打印出 p=0 q=1 这种可读结果。
第一版枚举直接用整数掩码：
int n = (int)vars.size();
if (n >= 31) throw runtime_error("变量数过大，请使用剪枝版本");
for (int mask = 0; mask < (1 << n); ++mask) {
bool val[26] = {false};
for (int i = 0; i < n; ++i)
val[vars[i] - 'a'] = (mask >> i) & 1;
if (!eval(root, val)) {
cout << "不是重言式，反例: ";
for (int i = 0; i < n; ++i)
cout << vars[i] << "=" << ((mask >> i) & 1) << " ";
cout << endl;
return 0;
}
}
cout << "是重言式" << endl;
这段代码里 1 << n 是个硬边界：当 n 到 31 时， 1 << 31 会溢出变成负数，枚举立刻乱套。所以变量数超过 30 时直接提示换剪枝版本。变量数在 10 以内时暴力枚举完全够用，这也是课程设计报告里最容易被接受的第一版方案。
3.2 短路求值：一次递归里省掉一半无用功
枚举框架定了以后，每个组合都要对表达式树求一次值。求值本身是递归后序遍历，但如果老老实实把整棵树都算完，很多分支是白算的。比如 p & q ，只要 p 为假， q 根本不用看。这类逻辑上的短路规则帮我们把单次求值的成本降下来。
bool eval(Node* n, const bool val[26]) {
if (isalpha(n->op)) return val[n->op - 'a'];
switch (n->op) {
case '!': return !eval(n->left, val);
case '&':
if (!eval(n->left, val)) return false; // 左为假，整体必假
return eval(n->right, val);
case '|':
if (eval(n->left, val)) return true; // 左为真，整体必真
return eval(n->right, val);
case '>':
if (!eval(n->left, val)) return true; // 前件假，蕴含必真
return eval(n->right, val);
case '~':
return eval(n->left, val) == eval(n->right, val);
default:
throw runtime_error("未知节点类型");
}
}
& 和 | 的短路不影响最终值，因为 0 & x 恒为 0， 1 | x 恒为 1。 > 的短路用的规则是“假蕴含任何东西”，也就是前件为假时结果一定是真，这时右子树也不用算了。 ~ 两边都得算完才能比较，短路空间不大。
要注意的是，这种短路是“程序级”的优化，它没有减少枚举的 2 的 n 次方次调用，只是让一部分调用不用遍历整棵树。报告里写复杂度时要分清楚：最坏时间复杂度仍然是 O(2^n × m)，m 是表达式树的节点数，但平均表现会好不少。
3.3 部分赋值剪枝：三值逻辑直接砍掉整棵子树
暴力枚举的痛点在于，很多组合没必要看。比如 (p & q) | !(p & q) 这个公式，一旦 p 赋成 false ， p & q 已经确定为假，整个公式变成 false | !false ，也就是恒真。这时继续枚举 q 的取值纯属浪费。
部分赋值剪枝的做法是：在变量还没全部赋值时就对表达式树做三值逻辑求值。每个节点返回三种状态：确定为真、确定为假、仍未定。如果整棵树已经确定为真，那这一支往下怎么枚举都是真，直接剪掉；如果已经确定为假，那这一支全是反例，也直接剪掉。
// 三值逻辑：0 表示确定为假，1 表示为真，2 表示未定
int eval3(Node* n, const bool val[26], const bool assigned[26]) {
if (isalpha(n->op)) {
if (!assigned[n->op - 'a']) return 2;
return val[n->op - 'a'] ? 1 : 0;
}
if (n->op == '!') {
int v = eval3(n->left, val, assigned);
return v == 2 ? 2 : 1 - v;
}
int l = eval3(n->left, val, assigned);
if (n->op == '&') {
if (l == 0) return 0;
int r = eval3(n->right, val, assigned);
if (r == 0 || r == 2) return r; // 右为 0 则整体 0；右未定则整体未定
return l == 2 ? 2 : 1; // l=1, r=1 才为真
}
if (n->op == '|') {
if (l == 1) return 1;
int r = eval3(n->right, val, assigned);
if (r == 1 || r == 2) return r;
return l == 2 ? 2 : 0; // l=0, r=0 才为假
}
if (n->op == '>') {
if (l == 0) return 1;
if (l == 1) return eval3(n->right, val, assigned);
int r = eval3(n->right, val, assigned);
if (r == 1) return 1; // x > 1 恒真
return 2;
}
if (n->op == '~') {
if (l == 2) return 2;
int r = eval3(n->right, val, assigned);
if (r == 2) return 2;
return l == r ? 1 : 0;
}
return 2;
}
这个求值器是“偏保守”的，有些已经能定的情况我选择返回“未定”。少剪几刀不会影响正确性，只影响速度。真正不能错的是：返回 0 或 1 必须保证在任意补齐剩余变量后结果都成立，这一点上面的规则都满足。
有了 eval3 ，递归枚举函数就可以在深入一层之前先试探整棵树：
bool check(Node* root, const vector<char>& vars, int idx,
bool val[26], bool assigned[26], int& failMask) {
if (idx == (int)vars.size()) {
if (!eval(root, val)) {
failMask = 0;
for (int i = 0; i < (int)vars.size(); ++i)
if (val[vars[i] - 'a']) failMask |= (1 << i);
return false;
}
return true;
}
// 部分赋值剪枝：已经赋过的变量足够确定整棵树的值
if (idx > 0) {
int v = eval3(root, val, assigned);
if (v == 0) {
failMask = 0;
for (int i = 0; i < idx; ++i)
if (val[vars[i] - 'a']) failMask |= (1 << i);
return false; // 这一支全是假，且已给出反例
}
if (v == 1) return true; // 这一支全是真，剪掉
}
int c = vars[idx] - 'a';
assigned[c] = true;
val[c] = false;
if (!check(root, vars, idx + 1, val, assigned, failMask)) return false;
val[c] = true;
if (!check(root, vars, idx + 1, val, assigned, failMask)) return false;
assigned[c] = false; // 回溯
return true;
}
递归函数按变量顺序深度优先枚举，每一层先试 false 再试 true 。注意 failMask 的编码方式：完整赋值时记录全部位数；剪枝发现整支为假时，只记录到当前层 idx 为止的已赋值变量，未赋位的位默认是 0，也能当反例用，因为部分赋值下公式已经确定为假，剩下的变量随便填什么都是假。
3.4 反例输出与判别结果解读
把上面几块拼起来，主函数长这样：
int main(int argc, char** argv) {
if (argc < 2) {
cerr << "用法: ./tauto \"表达式\"" << endl;
return 1;
}
string expr = argv[1];
vector<string> tokens = tokenize(expr);
validateTokens(tokens);
vector<string> postfix = infixToPostfix(tokens);
Node* root = buildTree(postfix);
vector<char> vars = collectVars(root);
bool val[26] = {false};
bool assigned[26] = {false};
int failMask = -1;
bool isTauto = check(root, vars, 0, val, assigned, failMask);
if (isTauto) {
cout << "是重言式" << endl;
} else {
cout << "不是重言式，反例: ";
for (int i = 0; i < (int)vars.size(); ++i)
cout << vars[i] << "=" << ((failMask >> i) & 1) << " ";
cout << endl;
}
return 0;
}
跑两个例子：
$ ./tauto "p > (q > p)"
是重言式
$ ./tauto "p & !q"
不是重言式，反例: p=0 q=0
p > (q > p) 是经典公理 K 的实例，任何赋值下都真； p & !q 在 p=0 q=0 时明显为假，判别器给出第一组反例就停了。这里注意在 shell 里执行时，含 ! 的表达式最好用单引号包起来，比如 ./tauto 'p | !p' ，避免 ! 被终端的历史展开机制吞掉。
4. 从判别器到课程设计报告：交付物里必须有这三样东西
4.1 三份必测用例：恒真、可满足、矛盾各来一组
判别器写完后，课程设计报告里最容易被挑刺的就是测试部分。至少要有三类用例：一类是重言式，一类是可满足但非重言式，一类是矛盾式（所有赋值都为假）。这三类的期望输出是截然不同的。
| 输入表达式 | 公式类型 | 期望输出 |
|---|---|---|
| `p | !p` | 重言式（排中律） |
p & q | 可满足式 | 不是重言式，反例: p=0 q=0 |
p & !p | 矛盾式 | 不是重言式，反例: p=0 |
注意 p & !p 这种矛盾式，判别器输出的反例是第一组碰到的赋值 p=0 。这没问题，因为矛盾式在所有赋值下都假，任何一个反例都成立。报告里最好写明“反例不唯一，程序输出最先枚举到的那一组”，避免答辩时被问“为什么不是另一个反例”。
测试表格最好加上“实际输出”列，直接截图或复制终端输出。这样报告的可信度比你用文字描述“正确”高得多。
4.2 复杂度与规模边界：变量数到 20 就该换打法
复杂度分析是数据结构与算法课程设计的必写章节。设公式解析得到的表达式树节点数为 m，变量数为 n，那么：
| 阶段 | 时间复杂度 | 空间复杂度 |
|---|---|---|
| 词法扫描 + 中缀转后缀 | O(m) | O(m) |
| 后缀建树 | O(m) | O(m) |
| 暴力枚举 + 短路求值 | 最坏 O(2^n × m) | O(m) + 递归栈深 |
| 部分赋值剪枝 | 最坏仍是 O(2^n × m)，实际远好于暴力 | O(m) + 递归栈深 |
实际选择策略时，我一般按变量数量分档：
| 变量数 n | 建议方案 |
|---|---|
| n ≤ 10 | 直接暴力枚举，代码简单，报告好写 |
| 10 < n ≤ 20 | 短路求值足够 |
| 20 < n ≤ 30 | 部分赋值剪枝有明显收益 |
| n > 30 | 暴力不可行，建议换可满足性求解思路 |
“可满足性求解”在课程设计里通常不作为硬性要求，但报告末尾可以写一句：对于变量数较大的场景，可以把重言式判别转化为“否定公式的可满足性判别”，借助更专业的求解思路处理。这能体现你对算法边界的理解，也是加分项。
4.3 课程设计报告的骨架：把过程和踩坑写进文档
课程设计报告不是把所有代码贴一遍就完事，重点是让老师看到你“为什么这样设计”。我建议按六节组织：
需求分析：复述重言式判别问题，列出输入输出约定，尤其是运算符优先级表，直接抄第 2.1 节的表。 概要设计：把程序拆成词法扫描、中缀转后缀、表达式树构建、真值枚举四个模块，用文字或框图说明每个模块的输入输出。这里不用画复杂图，用箭头描述数据流即可。 详细设计：给出 Node 结构体、核心函数原型，重点解释为什么用二叉树而不是直接在中缀字符串上求值。原因就是中缀字符串求值每次都要重看优先级，而树结构把优先级关系固化在了结构里。 编码实现：放核心代码片段，不用全文贴；更别提“我贴了全部代码”，报告篇幅有限。 测试：放第 4.1 节的表格和终端输出截图，再加第 6 章的随机验证结果。 总结：写复杂度结论、当前实现的局限（比如变量数限制）、可改进方向。
5. 重言式判别避坑清单：5 个能让程序秒变黑匣子的细节
5.1 优先级表不一致：同一公式两套结果
现象：别人写的 p > q & r 判出来是重言式，你的判出来不是；或者同一个公式在改了一处运算符优先级常量后结果完全相反。 原因：不同教材对蕴含和与运算的优先级定义不统一，代码里如果有多处硬编码的优先级判断，改了一处漏了一处，解析结果就会分叉。 解决：把优先级收敛成第 2.1 节那个 priority() 函数，所有比较都走它；报告开头写明“本文约定优先级为 ! > & > | > > 与 ~”。测试里专门放 p > q & r 这类有歧义边界的式子，用输出确认实际解析结构和你的约定一致。
5.2 一元非当成二元运算：!!p 和 a!b 双双翻车
现象：输入 !!p 输出错误结果；输入 a!b 居然也通过了，还给出一个莫名其妙的“重言式”结论。 原因：一元 ! 在算法里被当成普通二元运算符处理，出栈条件和结合性都没有单独约定，导致非运算符作用的操作数不对。 解决： ! 只允许出现在一个操作数前面，且优先级定为最高、右结合。词法扫描后的 validateTokens 要能挡掉 a!b 这种“变量后面紧跟一元运算符、运算符后面紧跟变量”的非法模式。简单做法是：一个 token 是变量或右括号时，下一个 token 必须是二元运算符或右括号；一个 token 是二元运算符时，下一个 token 必须是变量或 ! 或左括号。
5.3 递归深度失控：深层括号把调用栈打穿
现象：输入一个几千层括号嵌套的表达式，程序直接段错误或崩溃。 原因： eval 和 eval3 都是递归实现，递归深度等于表达式树的高度。二叉表达式树如果长得极不平衡，深度可能逼近节点数，几百层就够压垮默认栈。 解决：给输入表达式设置长度上限，比如 2000 字符且括号深度不超过 1000，超出就报错。更根本的做法是让 eval 用显式栈做后序遍历代替递归，但课程设计阶段设置上限更实用。报告里写明“递归深度为 O(m)”，让老师知道你不是没考虑。
5.4 枚举循环里反复拷贝变量集合：常数比你还聪明
现象：变量数 n=12 时暴力枚举要跑几秒，明明逻辑很简单却慢得出奇。 原因：如果把变量收集放在枚举循环内，或者每次递归都用 unordered_map<char,bool> 当环境变量表，构造析构成本会被放大到 2^n 倍。这类常数问题让枚举算法从“秒回”变成“喝茶”。 解决：变量表只收集一次，环境用 bool val[26] 数组加 bool assigned[26] 数组，按需赋值和回溯。26 个 bool 的数组开销是固定的，远小于任何哈希表。第 3.3 节 check 函数里就是这么组织的。
5.5 非法输入不拦截：靠“不报错”骗自己
现象：输入 @p&q 或 (p&q ，程序不报错，甚至偶尔输出“是重言式”。 原因： tokenize 放行了未知字符，或者 infixToPostfix 在遇到右括号、表达式结束时没有检查操作符栈的状态，非法括号被静默处理。 解决：三处必须兜底—— tokenize 遇到非法字符直接抛异常；右括号弹栈时检查栈里还有没有 ( ；表达式结束后检查操作符栈是否为空，如果有剩余运算符说明括号不匹配或运算符缺失。这些错误处理代码虽然不参与“判别”本身，但没有它们，程序一旦遇到脏输入就会变成黑匣子，输出的结果你根本不敢信。
6. 用随机生成器批量验证：让判别器自己给自己出题
人工测试用例如上面那样列五六个就差不多了，但还有一个更狠的验证方法：随机生成公式批量考验判别器。我习惯写一个 Python 脚本，生成两类公式：一类是确定的重言式，一类是随机公式，然后用子进程调 C++ 判别器，比对结果。
import random
import subprocess
random.seed(2024) # 固定种子，方便复现
def rand_formula(vars, depth):
if depth == 0 or random.random() < 0.3:
return random.choice(vars)
if random.random() < 0.2:
return "!" + rand_formula(vars, depth - 1)
op = random.choice(["&", "|", ">", "~"])
left = rand_formula(vars, depth - 1)
right = rand_formula(vars, depth - 1)
return f"({left} {op} {right})"
def make_tautology(vars):
# (A | !A) 对任意子式 A 恒真，随机变体也是重言式
a = rand_formula(vars, 2)
return f"({a} | !{a})"
for i in range(200):
vars = random.sample("pqrstuvwxyz", random.randint(2, 6))
expr = make_tautology(vars)
result = subprocess.run(
["./tauto", expr], capture_output=True, text=True
)
if result.stdout.strip() != "是重言式":
print("恒真式误判:", expr)
break
else:
print("200 个随机重言式全部判对")
脚本的关键参数有两个： random.seed(2024) 保证每次跑的结果可复现，报告里可以写“本次测试固定随机种子 2024”； depth 控制在 2 到 4，生成的公式不会太长也不会每个都是单变量。 make_tautology 的构造逻辑是先用随机子式 A 拼出 (A | !A) ，这个公式无论 A 取什么值都恒真，所以生成 200 个变体全部应该判“是重言式”。
第二类用例是把 make_tautology 换成 rand_formula(2, 4) ，也就是纯随机公式。这里不需要断言具体比例，但如果随机公式被判成重言式的比例高得离谱，比如超过一半，基本可以断定是解析或建树环节出了问题，优先级表被写反了。随机生成器的价值就在这里：它能用几百个不重样的输入，把手工测试覆盖不到的边界组合冲开，比对着常规公式玄学调参可靠多了。
我最后养成的习惯是：拿到这类题目先写运算符约定表，再写 tokenize ，最后才碰枚举逻辑；代码跑完固定种子和随机用例，再提交报告，少很多答辩现场翻车。希望帮到你。
扫一扫
1296
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
