• Sun 2019.08.11


    "If the fractional portion of the argument is greater than 0.5, the argument is rounded to the integer with the next higher absolute value. If it is less than 0.5, the argument is rounded to the integer with the lower absolute value. If the fractional portion is exactly 0.5, the argument is rounded to the next integer in the direction of +8. Note that this differs from many languages' round() functions, which often round this case to the next integer away from zero, instead giving a different result in the case of negative numbers with a fractional part of exactly 0.5."

    While rounding towards positive infinity does work for negative numbers, it is not rounding
    correctly for exact 0.5 values.

    >console.log(Math.round(-100.6), Math.round(-100.4), Math.round(-101.5), Math.round(-100.5));
    -101 -100 -101 -100
    >console.log(Math.round(100.6), Math.round(100.4), Math.round(101.5), Math.round(100.5));
    101 100 101 100

    Correct values
    > -101 -100 -101 -100
    > 101 100 102 101

      VERSION: "2v04",
      GIT_COMMIT: "3956264e",


    Had a thought, could this anomaly be related to the floating point number of digits to right of zero not matching different browsers and node.js output? hmmmm. . . .

    test files #1

    EDIT: Tue 2019.08.20

    see snippet that may be helpful in resolving this

  • @Robin

    If you like take a look at the source code to find and fix the error ;-)

  • Or it it might be related to this issue


  • Just to add:

    $ ./espruino
    >(new Float64Array([101.5])).buffer
    =new Uint8Array([0, 0, 0, 0, 0, 96, 89, 64]).buffer
    $ node
    > (new Float64Array([101.5])).buffer
    ArrayBuffer { byteLength: 8 }
    > new Uint8Array((new Float64Array([101.5])).buffer)
    Uint8Array [ 0, 0, 0, 0, 0, 96, 89, 64 ]

    So this would appear not to be a parsing issue (like 1573) but is to do with the rounding code itself

  • It seems like Math.round() is a better solution, but it is not! In some cases it will NOT round correctly. Also, toFixed() will NOT round correctly in some cases.

    To correct the rounding problem with the previous Math.round() and toFixed(), you can define a custom JavaScript round function that performs a "nearly equal" test to determine whether a fractional value is sufficiently close to a midpoint value to be subject to midpoint rounding. The following function return the value of the given number rounded to the nearest integer accurately.

    Number.prototype.roundTo = function(decimal) {
    return +(Math.round(this + "e+" + decimal) + "e-" + decimal);

    var num = 9.7654;
    console.log( num.roundTo(2)); //output 9.77

  • Do you think this is an issue specific to Espruino?

    If so, maybe you could look at helping to contribute a fix for it?

  • I also think Math.round() does not behave as expected


    Math.round(1.5) should return 2

  • Thanks - just created a new issue for this: https://github.com/espruino/Espruino/iss­ues/2258

    Not sure how that happened as that's pretty much the first thing you'd test when implementing Math.round!

  • That reminds me: I was planning to report


    but totally forgot about it (whoops).

    Edit: reported now

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Math.round() doesn't follow specification for exact 0.5

Posted by Avatar for Robin @Robin