float == 和 != 不是直接对立的情况
Cases where float == and != are not direct opposites
在https://github.com/numpy/numpy/issues/6428, the root cause for the bug seems to be that at simd.inc.src:543中，编译器将!(tmp == 0.)优化为tmp != 0.。
A comment 说这些是 "not quite the same thing." 但没有指定任何细节。进一步提到了 NaN，但测试表明 NaN 与预期方式 0. 相比。
什么情况下==和!=都可以returntrue/false?
或者差异在另一个领域 - 例如returning 具有相同真值但与整数不同的值（但测试显示即使这似乎并非如此）?
A comment says that these are "not quite the same thing." But doesn't specify any details. NaNs are mentioned further on, but a test shows that a NaN compares to 0. the expected way.
What are the cases where == and != can both return true/false?
标准说：
The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. [...] For any pair of operands, exactly one of the relations is true.
（C2011，6.5.9/3；已强调）
因此，对于允许共同作为这些运算符的操作数的任何表达式 X 和 Y，(X) != (Y) 的计算结果必须与 !((X) == (Y)) 相同。如果在实践中发现他们不这样做，那么产生该结果的编译器在这方面是不符合要求的。如果这种不符合是意外的，那么它构成了编译器中的错误。
此外，我观察到 6.5.9/3 与任何其他操作数一样适用于 NaN、无穷大和次正规。由于不同的原因，NaN 对于这些运算符来说是特殊的：NaN 与所有操作数相比都不相等，包括它们自己（假设 IEEE 语义）。
来自链接post：
charris commented on Oct 9, 2015
I'm going to guess the !(tmp == 0.) is optimized to tmp != 0., which is not quite the same thing.
OP 的评论：
The author says it's a guess but they are quite positive that !(tmp==0.) and tmp!=0. are not equivalent and express that as if it's common knowledge
我们如何协调这两者？
很明显，它们在逻辑上是等价的。但在实施方面，他们可能不是。编译器可能将 !(a == b) 实现为测试 a == b 后跟一个否定。或者，它可能会优化表达式，并直接测试 a != b。在这两种情况下，生成的汇编代码会有所不同。应该（必须）达到相同的结果，但执行时间可能不同。
"not quite the same thing" 只是承认 !(a == b) 和 a != b 实际上是不同的字符组合，编译器可能会对它们做一些技术上不同的事情，但必须产生相同的结果.如果观察到不同的结果，则编译器中可能存在错误。
在https://github.com/numpy/numpy/issues/6428, the root cause for the bug seems to be that at simd.inc.src:543中，编译器将!(tmp == 0.)优化为tmp != 0.。
A comment 说这些是 "not quite the same thing." 但没有指定任何细节。进一步提到了 NaN，但测试表明 NaN 与预期方式 0. 相比。
什么情况下==和!=都可以returntrue/false?
或者差异在另一个领域 - 例如returning 具有相同真值但与整数不同的值（但测试显示即使这似乎并非如此）?
A comment says that these are "not quite the same thing." But doesn't specify any details. NaNs are mentioned further on, but a test shows that a NaN compares to 0. the expected way.
What are the cases where == and != can both return true/false?
标准说：
The
==(equal to) and!=(not equal to) operators are analogous to the relational operators except for their lower precedence. [...] For any pair of operands, exactly one of the relations is true.
（C2011，6.5.9/3；已强调）
因此，对于允许共同作为这些运算符的操作数的任何表达式 X 和 Y，(X) != (Y) 的计算结果必须与 !((X) == (Y)) 相同。如果在实践中发现他们不这样做，那么产生该结果的编译器在这方面是不符合要求的。如果这种不符合是意外的，那么它构成了编译器中的错误。
此外，我观察到 6.5.9/3 与任何其他操作数一样适用于 NaN、无穷大和次正规。由于不同的原因，NaN 对于这些运算符来说是特殊的：NaN 与所有操作数相比都不相等，包括它们自己（假设 IEEE 语义）。
来自链接post：
charris commented on Oct 9, 2015
I'm going to guess the
!(tmp == 0.)is optimized totmp != 0., which is not quite the same thing.
OP 的评论：
The author says it's a guess but they are quite positive that
!(tmp==0.)andtmp!=0.are not equivalent and express that as if it's common knowledge
我们如何协调这两者？
很明显，它们在逻辑上是等价的。但在实施方面，他们可能不是。编译器可能将 !(a == b) 实现为测试 a == b 后跟一个否定。或者，它可能会优化表达式，并直接测试 a != b。在这两种情况下，生成的汇编代码会有所不同。应该（必须）达到相同的结果，但执行时间可能不同。
"not quite the same thing" 只是承认 !(a == b) 和 a != b 实际上是不同的字符组合，编译器可能会对它们做一些技术上不同的事情，但必须产生相同的结果.如果观察到不同的结果，则编译器中可能存在错误。