2.9999999999999999 >> .5?

后端 未结 10 2152
悲&欢浪女
悲&欢浪女 2021-02-07 16:04

I heard that you could right-shift a number by .5 instead of using Math.floor(). I decided to check its limits to make sure that it was a suitable replacement, so I checked the

相关标签:
10条回答
  • 2021-02-07 16:12

    If you wanna go deeper, read "What Every Computer Scientist Should Know About Floating-Point Arithmetic": http://docs.sun.com/source/806-3568/ncg_goldberg.html

    0 讨论(0)
  • 2021-02-07 16:14

    Actually, you're simply ending up doing a floor() on the first operand, without any floating point operations going on. Since the left shift and right shift bitwise operations only make sense with integer operands, the JavaScript engine is converting the two operands to integers first:

    2.999999 >> 0.5
    

    Becomes:

    Math.floor(2.999999) >> Math.floor(0.5)
    

    Which in turn is:

    2 >> 0
    

    Shifting by 0 bits means "don't do a shift" and therefore you end up with the first operand, simply truncated to an integer.

    The SpiderMonkey source code has:

    switch (op) {
      case JSOP_LSH:
      case JSOP_RSH:
        if (!js_DoubleToECMAInt32(cx, d, &i)) // Same as Math.floor()
            return JS_FALSE;
        if (!js_DoubleToECMAInt32(cx, d2, &j)) // Same as Math.floor()
            return JS_FALSE;
        j &= 31;
        d = (op == JSOP_LSH) ? i << j : i >> j;
        break;
    

    Your seeing a "rounding up" with certain numbers is due to the fact the JavaScript engine can't handle decimal digits beyond a certain precision and therefore your number ends up getting rounded up to the next integer. Try this in your browser:

    alert(2.999999999999999);
    

    You'll get 2.999999999999999. Now try adding one more 9:

    alert(2.9999999999999999);
    

    You'll get a 3.

    0 讨论(0)
  • 2021-02-07 16:14

    Try this javascript out: alert(parseFloat("2.9999999999999997779553950749686919152736663818359374999999"));

    Then try this: alert(parseFloat("2.9999999999999997779553950749686919152736663818359375"));

    What you are seeing is simple floating point inaccuracy. For more information about that, see this for example: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems.

    The basic issue is that the closest that a floating point value can get to representing the second number is greater than or equal to 3, whereas the closes that the a float can get to the first number is strictly less than three.

    As for why right shifting by 0.5 does anything sane at all, it seems that 0.5 is just itself getting converted to an int (0) beforehand. Then the original float (2.999...) is getting converted to an int by truncation, as usual.

    0 讨论(0)
  • 2021-02-07 16:18

    The shift right operator only operates on integers (both sides). So, shifting right by .5 bits should be exactly equivalent to shifting right by 0 bits. And, the left hand side is converted to an integer before the shift operation, which does the same thing as Math.floor().

    0 讨论(0)
  • 2021-02-07 16:19

    It should be noted that the number ".0000000000000007779553950749686919152736663818359374" is quite possibly the Epsilon, defined as "the smallest number E such that (1+E) > 1."

    0 讨论(0)
  • 2021-02-07 16:25

    I suspect that converting 2.9999999999999997779553950749686919152736663818359374999999 to its binary representation would be enlightening. It's probably only 1 bit different from true 3.

    0 讨论(0)
提交回复
热议问题