2017-08-07 46 views
1

我正在阅读关于fpectl - 浮点异常控制the Python documentation为什么fpectl - 浮点异常控制如此危险?

它警告用户说

......而它的使用气馁,可能是除专家之手的危险。有关更多详细信息,另请参阅限制和其他限制条件部分。

为什么?

阅读链接的网页并没有帮助我。

+0

最值得注意的是:“设置一个给定的处理器来捕捉IEEE-754浮点错误,当前需要在每个架构的基础上定制代码。 '和'fpectl模块不是线程安全的。“不同的体系结构处理浮点数的方式不同,因此需要定制异常本身。 –

+0

在这一点上,它也基本上被破坏和无法维护。请参阅[本主题](https://mail.python.org/pipermail/python-dev/2017-January/147094.html)。 –

回答

1

由于种种原因,“不驾驶防守”的方式是不安全的。你可以做到这一点,没有任何麻烦。或者你可能会倒霉,跑到马路上,穿过中间位置,进入迎面而来的交通。

几个原因为什么它充其量混乱,难以使得用它来创建安全,可靠的代码非常困难的方式来思考:

  1. 它不是线程安全的。这意味着它将在线程 与非线程程序中有所不同,在几乎每个线程化程序中可能以不同方式以不同方式 。
  2. 根据 特定浮点实现,其支持代码的需求和行为可能会有很大差异。因此,如果您的代码正确地运行 ,那并不意味着您可以将其代码 安全地分发给其他系统或其他可能在不同CPU系列(例如ARM vs x86 vs POWER)上运行它的用户,或相同CPU家族的不同 代(例如,AMD与x86的英特尔 实现)。
  3. 浮点代码在 IEEE-754时代非常便携。但 仍然存在微妙的不完善之处 那些做 numerical algorithms 小心预防。了解边界 条件,浮点近似 在这些边缘处的行为(或无法表现),以及不同的FP实现如何处理它们仍然是 重要。减少变量是限制编写这些算法的风险的关键方法。 使用了解不完整的标准,很少使用的 异常处理模块与“降低风险”的 相反。
  4. 风险涉及数据完整性。有可能的是,压制 例外会让不良或不一致的数据进入进一步的计算。 异常就像疼痛。 系统信号有问题或“不要那么做!” 关闭它导致未捕获的数据损坏在数值处理 中有很长的历史。在这个普遍支持 NaNInf的年代,这比过去的年龄更不可能, ,因为带内(在数据值中)信令机制 可以是替代指标。但是,如果不研究 源代码,您是否真的知道的 位置的数据会发生什么变化?你是否可以保证,如果它在矢量或标量FP指令中处理,结果将与 的结果相同? 令人怀疑。 您的代码是否知道NaN与 之间的差异 与一般的缺失数据之间的差异?可能不会。这么多新的 不确定的结果!
  5. 该文档本身基本上警告“你将需要 下拉菜单并研究源代码,看看它是如何工作的。” 这是一个重要的三重黑钻石路径。 由于某种原因,它们不能在标准构建中启用它。 如果你不是 已经理解了旅行 的数值分析是否适合你,那不适合你。