因果关系、INUS定义和SUPPES定义

本文探讨了因果关系的重要性及其在哲学中的地位,介绍了INUS定义和SUPPES定义两种因果关系的定义方法,并通过实例解析了如何运用这两种定义来判断因果关系。

原文地址:http://wt.vankeweekly.com/blog/%B4%F3%CA%AB/articles/11884.html


因果关系、INUS定义和SUPPES定义

我们知道,因果关系对于我们想任何问题和做任何事情,都是非常重要的。甚至有很多人认为,天赋的因果联想能力,是人类得以成为“万物之灵长”的首要条件之一。在哲学上,确实存在怀疑甚至否定因果关系的意见,而且这些意见甚至不可能被驳倒。但这些意见说来玩玩可以,不可以当真,因为否定因果关系,导致的只能是不可知论。

离开因果关系,我们通过经验获取知识就成为几乎不可能的事情。赫拉克利特的诅咒就要成为现实,真实世界对于我们来说变成一条永远不可能再次踏入的河流。我们所能收获的,只能是一个一个碎片状、彼此毫无关系的观测语句。而且这些语句都是关于过去的,对我们预知未来,或者采取行动以应付未来毫无帮助。这样的世界当然是非常可怕的。

我们似乎天生就有建立因果联想的能力,也有这种冲动。比如说,我们被一株荆棘刺伤了之后,见了其他尖尖的硬东西就会躲开。再比如说,我们从小就喜欢问“为什么”,得到了一个回答就会觉得快乐。但究竟什么是因果关系,或者说如何鉴别是否因果关系,就不是每一个人能够讲得清楚的了。

在因果关系理解上的含混或者分歧,会严重阻碍人们之间达成共识。因果关系的确定,有时候会影响“责任”的划分,有时候会影响“当前应该做什么”之类的决定。如果双方对因果关系的界定不统一,就会发生无谓的争论。

建立因果关系,也是科学的一个本能冲动。因果关系是非常有说服力的,“知识就是力量”,这个力量很大程度上来自因果观念。所以,如果对因果关系认识胡涂,科学研究的结果只怕也是很糊涂的。进而把这样胡涂的结论付诸实践,那就非常危险了。

在因果关系问题上,最容易犯的错误是两个。一是将因果关系混同于充分/必要条件关系,在既不存在充分条件、也不存在必要条件的情况下,就认为不存在因果关系了。二是将因果关系混同于统计相关性关系,找到了数据上的正相关,就以为找到了因果关系。

这两种错误,前者通常对应于单个经验事件或比较直接的因果关联,后者通常对应于大量经验事件或比较复杂的因果关联。要避免犯这两种错误,我们就有必要了解因果关系的两种定义:INUS定义和SUPPES定义。

下面我们通过两个例子来分别说明。

第一个例子是,某甲将某乙从五楼上推下来,某乙落地后死掉了。通常情况下,某甲应该为此负责,因为我们认为某甲推某乙下楼是某乙死亡的原因。但如果用充分/必要条件关系来检验,这个因果关系就不成立。因为即使某乙不被推下去,他也未必不死,所以某甲推某乙下楼不是必要条件。另一方面,如果某乙落地的地方刚好是一个充气垫子,或者某乙身负绝世轻功,那么他即使被推下去也未必死,所以这里也不存在充分条件。

这和我们的常识显然是相悖的。由此可见,因果关系不一定是充分条件关系,也不一定是必要条件关系。在这里我们需要INUS定义,它可以帮助我们解决这一问题。

INUS定义是一个叫马奇的人提出来的,所以它也被称为“马奇定义”。INUS是它的定义的缩写:

An insufficient but necessary part of a condition which is itself unnecessary but sufficient for the result.(结果的一个不必要但是充分的条件中,一个不充分但是必要的组成部分

这句话可以进一步简缩一下,就是:

所谓原因,就是结果的一个充分条件组中的一个必要组成部分。

也就是说,假设A和B是两个事件,那么在以下的情况下,我们称A是B的原因:

  1. A加上其他某些事件,可以组成一个复合条件C,C是B的充分条件;
  2. 如果把A从C中间拿掉,C就不再是B的充分条件。

套用到我们上面的例子中,不难发现:

  1. “某甲推某乙下楼”加上“楼下是硬地”加上“某乙不会绝顶轻功”是“某乙死亡”的充分条件;
  2. 单纯“楼下是硬地”加上“某乙不会绝顶轻功”不是“某乙死亡”的充分条件。

由此我们可以得到结论,“某甲推某乙下楼”是“某乙死亡”的原因。

当然,从上面我们也可以看出,一个结果通常不止一个原因。那么,什么是“主要原因”呢?被“辩证法”搞胡涂了的人可能会问这个问题。其实在逻辑上是没有什么“主要原因”可言的。只不过我们在实践中会根据语境来进行选择使用它们罢了。

比如“楼下没有充气垫子”和“某乙不会绝顶轻功”同样是“某乙死亡”的原因。但我们不会说某乙活该,或者去责问那块地的主人为什么不摆上一个充气垫子,这是因为我们在责任认定时,除了因果关系认定之外,还有“不能预计”、“不能选择”这样的免责条款。

INUS定义也可以帮助我们理解,为什么原因的原因不一定是原因,结果的结果也不一定是结果。

以上说的是单个经验事件。而对于大量经验事件,我们通常用统计方法进行分析。统计所能建立的是一种数据上的相关性。但是统计上的正相关,即使是非常高度的正相关,也并不等于因果关系。

有一个例子,说是有人做过统计,家里打火机数量越多,男主人患咳喘病的比例就越高。因此,在家里放太多打火机是致癌的原因。这个结论显然是荒谬的。我们一般的解释是,抽烟的人会有比较多的打火机,而抽烟的人患咳喘病的比例比较高。所以打火机多不是患咳喘病的原因,而是和患咳喘病一样,都是抽烟的结果。

但这个例子,确实说明了统计正相关不一定是因果关系。那么,有没有一个方法来验证统计正相关是否包含因果关系呢?在这里我们需要SUPPES定义。

SUPPES定义是一个叫Suppes的人提出来的。在这个定义中,概率上的正相关关系被称为“初步原因”。“初步原因”有可能是“真实原因”,也有可能是“虚假原因”。而成为真实原因的前提是:不存在一个这样的事件,在给定这一事件时,这个正相关关系趋于消失

在上面的例子中,我们可以发现,打火机数量显然是一个虚假原因。因为如果我们给定“抽烟”这个校验事件,只考虑抽烟的人,或者只考虑不抽烟的人的话,这个正相关关系都趋于消失。

那么,“抽烟”是不是一个真实原因呢?迄今为止,我们似乎给不出任何事件,可以使得抽烟与患咳喘病的相关关系消失。但回答仍然是否定的。SUPPES定义中的所谓“真实原因”其实是不可能被确认的,因为“不存在一个证伪事件”本身就是一个不可确证的前提。

比如说,假定有一种基因,它既决定人会不会染上烟瘾,也决定人会不会患咳喘病。那么,分别对于有无这种基因的人来说,吸烟和患咳喘病之间的相关关系就消失了。

所以,SUPPES定义其实是给了我们一个证伪“初步原因”的方法。如果我们想要验证一种统计相关性是否包含因果关系,办法就是去寻找一个可让这种相关关系消失的条件。如果找到了,那么它就是一个虚假原因。而在没有找到之前,我们不妨假定它是一个真实原因。

因果关系除INUS定义和SUPPES定义之外,当然还有其他的定义方法。但就易于理解和应用而言,它们确实是最好的两种。在我看来,它和每一个人的思考和生活都息息相关,其重要价值毫不逊色于牛顿的力学定律,而使用频率则远远超过之。普及这样的常识,真应该从娃娃抓起。遗憾的是,我们的中学不开逻辑课,大学里也没有科学方法论课程。无怪乎逻辑混乱的文学青年会充塞于天地之间,而头脑胡涂的“学者”群也构成了这“文明古国”一道“亮丽的风景线”。

<think>嗯,用户这次的问题是关于GDB崩溃的情况。首先,我需要仔细看看用户提供的日志上下文信息。看起来用户在使用GDB加载一个core文件时遇到了段错误,导致core dumped。根据之前的对话,用户之前已经询问过GDB自身崩溃的处理方法,现在可能是在尝试之前建议的步骤后遇到了具体的问题。 用户提供的日志中有几个关键点需要注意。首先,用户运行的GDB版本是Red Hat Enterprise Linux 7.0.1-42.e15,这个版本可能比较旧,可能存在已知的bug。其次,日志中显示“no debugging symbols found”,说明GDB相关库(如libreadline)没有调试符号,这可能让问题难以诊断。另外,用户尝试加载的core文件是core-5322-gdb,这应该是GDB自己生成的core dump。 接下来,我需要考虑用户可能的操作步骤。用户可能在调试某个程序时,GDB自己崩溃了,于是按照之前指导的方法尝试分析GDB的core文件,但遇到了问题。这时候用户需要进一步的帮助来解决这个问题。 根据之前提供的解决方案,我应该检查GDB版本、系统环境、依赖库、资源限制等。现在用户的环境中使用的是较旧的GDB版本,所以升级到最新版本可能是首要步骤。另外,缺少调试符号可能导致无法获取详细的堆栈信息,建议用户安装带有调试符号的GDBlibreadline等依赖库。 另外,用户可能没有正确生成或分析core dump文件。需要确认core文件的路径权限是否正确,以及是否使用正确的命令加载core文件。例如,用户运行的命令是“gdb /usr/bin/edb core-5322-gdb”,但正确的应该是“gdb /usr/bin/gdb core-5322-gdb”,因为edb可能是一个笔误,或者用户可能混淆了可执行文件。 此外,用户提供的路径中有多个类似的目录,如conf、conf3、conf s等,可能存在路径拼写错误或环境变量配置问题,导致GDB无法正确访问所需文件。需要检查这些路径是否存在,以及权限设置是否正确。 还有,日志中显示“Segmentation fault (core dumped)”,这通常是由于内存访问错误引起的。可能的原因包括GDB自身的bug、损坏的库文件、或者系统资源不足。需要建议用户检查系统日志(如/var/log/messages或dmesg)以获取更多线索,同时使用Valgrind或GDB自身来调试GDB的崩溃。 最后,用户可能需要更换调试工具作为临时解决方案,比如使用lldb,或者使用strace跟踪系统调用,以确定崩溃时的具体操作。 总结起来,用户的问题可能涉及旧版GDB的bug、缺少调试符号、路径或权限问题,以及可能的系统环境异常。需要逐步引导用户检查这些方面,并提供具体的命令步骤来诊断解决问题。</think>--- ### **问题分析** 从日志中可观察到以下关键点: 1. **GDB 版本过旧**:`Red Hat Enterprise Linux 7.0.1-42.e15` 对应的 GDB 版本较老,可能包含已知 Bug。 2. **依赖库无调试符号**:`libreadline.so.5` 等库缺少调试符号,导致无法精确定位崩溃原因。 3. **Segmentation Fault**:GDB 在加载 core 文件时触发段错误,可能由内存损坏或版本兼容性问题导致。 --- ### **分步解决方案** #### 1. **升级 GDB 到新版** ```bash # CentOS/RHEL 7 升级步骤 sudo yum install devtoolset-9-gdb # 安装较新的 GDB 工具链 scl enable devtoolset-9 bash # 切换到新版本环境 gdb --version # 验证版本是否为 8.3+ ``` #### 2. **安装调试符号包** - **GDB 调试符号**: ```bash sudo debuginfo-install gdb # CentOS/RHEL ``` - **libreadline 调试符号**: ```bash sudo debuginfo-install readline # CentOS/RHEL ``` #### 3. **复现崩溃并分析** - 使用升级后的 GDB 加载 core 文件: ```bash gdb /usr/bin/gdb core-5322-gdb # 注意路径需匹配 (gdb) bt full # 查看完整堆栈 ``` - **关键操作**: - 检查崩溃时的函数调用链(如 `libreadline` 或 Python 脚本引擎相关调用)。 - 若堆栈显示 `libreadline.so` 相关错误,尝试更新或降级该库。 #### 4. **检查系统完整性** - **修复依赖库**: ```bash sudo yum reinstall readline # 重新安装 libreadline sudo yum check # 检查包一致性 ``` - **验证内存状态**: ```bash free -h # 检查内存余量 dmesg | grep -i "out of memory" # 查看内核日志是否提示内存不足 ``` #### 5. **替代调试方案** - **使用 `lldb` 替代**: ```bash sudo yum install lldb # 安装 LLVM 调试器 lldb -c core-5322-gdb # 加载 core 文件 ``` - **通过 `strace` 跟踪系统调用**: ```bash strace -f -o gdb_strace.log gdb /usr/bin/gdb core-5322-gdb ``` #### 6. **报告问题** - 若确认是 GDB Bug,按以下格式提交报告: ```plaintext 标题:GDB 7.0.1-42.e15 在加载 core 文件时触发段错误 内容: 1. 复现步骤:gdb /usr/bin/gdb core-5322-gdb 2. 堆栈跟踪(bt full 输出) 3. 操作系统及版本:CentOS/RHEL 7.x 4. 附加 strace 日志或 core dump(如可能) ``` - 提交地址:[GDB Bugzilla](https://www.gnu.org/software/gdb/bugs/) --- ### **总结建议** ```plaintext 升级 GDB → 安装调试符号 → 分析堆栈 → 检查库完整性 → 换用 lldb → 提交报告 ``` 若问题仍存在,请提供 `bt full` 的堆栈输出及 `dmesg` 日志以便进一步分析。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值