原文
自古 js 多奇葩, 语言层面上有许多坑, 入坑多了也就习惯了那就再多一个坑吧
javascript 在判断两个值是否相等时, 有两种方式 == 和 === 这两者的区别我就不多说了, 随便一本 js 书上都有, 总之一般情形下我们有这样的结论:== 省事, 但结果混乱, 很多情形下近乎伪科学, 不建议使用, 很多人更是视其为洪水猛兽, 避之不及(它的坑太多, 我写不完, 不写了);=== 很严谨, 在绝大多数情形下, 应该使用这个结论我是很认同的, 并且尽量这么做但是, javascript 作为一门任性的语言, 不打打脸怎么好玩呢那么一起来愉快地玩坏 === 吧
要玩坏 ===, 只需要用到 0 没错, 就是数字 0 在 javascript 中, 数字都是以浮点数的形式参与运算, 其编码规则遵循 IEEE_754 标准 ( 不等于 0.3 这个问题怪它!)重点也不是这个标准, 重点是按照这个标准, 数字编码会有一位符号位表示正负, 所以对于任何数字, 非正即负那么问题来了, 0 呢? 答案是 0 也是有正负的通常我们看到的, 它义的 0 都是 + 0, 但在 javascript 中 - 0 也是存在的而在实际运算中, 某些场景下, 计算结果会产生 + 0 和 - 0 的差异; 同样 + 0 和 - 0 参与计算时, 可能会导致不同的结果但在直观感受上, 很明显 + 0 和 - 0 应该是相等的才对, 于是 javascript 在语言层面上想消除这种差异, 所以:
看起来很合理, 虽然有点奇怪但是再看这样的运算:
这不科学, 明明判定为完全相同的值, 进行相同的运算后, 结果会不相等对于开发者而言, 我们并不能在任何场景下信任 ===, 它也有不靠谱的时候
应对这种不科学的情形也很简单:
- function isEqual(a, b){
- if (a !== b) return false;
- return a !== 0 || 1 / a === 1 / b;
- }
2015 年 5 月 14 日补充:
强调一下本文的重点吧, 我从来没想质疑正负 Infinity 不相等的问题, 我想分享的要点是: 在 js 中,+0 === -0, 但它们并不是完全相等的
2015 年 5 月 26 日补充:
头一回回复评论比正文还长集中整理一下吧
关于 IEEE_754 标准
这是一个使用二进制表示浮点数的方案, 应用很广泛它规定了一位符号位表示正负, 0 也不例外, 这是负 0 产生的原因这是带符号位的浮点数表示方案的通病, 当然, 不带符号位的方案就可以避免这个问题不过这个问题并不严重, 通常程序语言并不希望开发者知道负 0 的存在, 直接在语言层面上规定正 0 和负 0 相等, 这才是 +0 === -0 的本质原因
我说负 0 的问题并不严重, 是因为其使用场景少, 出 bug 机率低说到不严重, 肯定有严重的问题, 那就是浮点数精度的问题, 数值是精确的连续的; 而数值编码是离散的, 很多时候不准确的毕竟 32 位也好 64 位也好, 能表现的浮点数是有限的从 0.10.2 到 0.9, 真正能精确表达的只有 0.5, 其他的数字都是近似值你可以自己尝试一下, 不管 jsjava 还是 c++, 浮点数运算从来不可靠, 比如 并不等于 0.3 如果你有过 c++ 或者 java 编程经验, 很可能接触过一些奇葩的代码来处理浮点数比较, 比如定义一个精度 0.002f(假设), 如果
abs(floatA - floatB) <0.002f
, 则认为两者相等很反人类, 但没办法编程语言有错吗? 没有, 但现实就是要妥协
关于负 0
负 0 在数学上并没有意义, 0 是无符号的但如果一个数值趋向于 0, 那么它是有符号的, 可以为负但对于这种情况, IEEE_754 标准并没有定义所以实际开发场景中, 如果一个数值趋向于 0, 那么它就是 0, 此时, 负 0 就有意义了, 它可能代表的是趋向于 0 的负数本质上这还是 IEEE_754 精度, 或者表达范围的问题但当负 0 有了具体意义的时候, 再说 +0 === -0, 我觉得有待商榷的
负 0 常见吗
首先我要说负 0 不常见, 但绝不是大家想的通常不可能出现其实一些常见的简单的场景下就有可能出现 - 0 比如 Math.ceil(-0.1)Math.round(-0.1); 还有不常见的
Math.atan2(-1, Infinity)
等由正负 0 而产生不同计算结果的操作相对会更多一点, 比如文章中的举例的倒数运算
参考资料:
developer.mozilla.org/en-US/docs/
javascript 与 === 运算
通常情况下,=== 在 js 中, 表示判断类型和值是否都完全相等都说通常了, 肯定有反例很多熟悉 js 的人都知道这样一个知识点, NaN !== NaN 所以我们常常可以看到这样的代码:
- function isNaN (num){
- return num !== num;
- }
这就是编程语言为了满足直观的理解而操纵运算符的结果 + 0 和 - 0 同样是这样, 它们的编码并不同, 但却判定它们相等
对于以上两个点, EmacScript 6 中加入了 Object.is 方法来处理:
- Object.defineProperty(Object, 'is', {
- value: function(x, y) {
- if (x === y) {
- // 0 === -0, but they are not identical
- return x !== 0 || 1 / x === 1 / y;
- }
- // NaN !== NaN, but they are identical.
- // NaNs are the only non-reflexive value, i.e., if x !== x,
- // then x is a NaN.
- // isNaN is broken: it converts its argument to number, so
- // isNaN("foo") => true
- return x !== x && y !== y;
- },
- configurable: true,
- enumerable: false,
- writable: true
- });
参考资料:
- wiki.ecmascript.org/doku.php?id
- developer.mozilla.org/en-US/docs/
对于负 0 的问题, EmacScript 5 中同样加入了 isNegative0 来处理 - 0
参考资料:
www.wirfs-brock.com/allen/posts
不仅如此, 一些工具类库中也加入了类似的处理, 如 underscore 的 isEqual 方法
So...
对于绝大部分开发场景而言,-0 根本没有存在感; 但我把这个点分享出来, 让更多的人知道有 - 0 这个东西, 让更多的人知道可能存在看似相同的输入, 经过相同的计算, 产生完全不同结果的可能, 避免他们遭遇奇怪的 bug
来源: https://juejin.im/post/5aa94e97f265da239a5f8394