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

• #3
Or it it might be related to this issue

• #4
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

• #5
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 
• #6
Do you think this is an issue specific to Espruino?
If so, maybe you could look at helping to contribute a fix for it?

• #7
I also think Math.round() does not behave as expected
Math.round(1.3) =1 >Math.round(1.4) =1 >Math.round(1.5) =1 >Math.round(1.6) =2 >Math.round(1.0) =1
Math.round(1.5)
should return 2 
• #8
Thanks  just created a new issue for this: https://github.com/espruino/Espruino/issues/2258
Not sure how that happened as that's pretty much the first thing you'd test when implementing Math.round!

• #9
That reminds me: I was planning to report
Math.ceil(Math.sqrt(9))
=4but totally forgot about it (whoops).
Edit: reported now
Sun 2019.08.11
While rounding towards positive infinity does work for negative numbers, it is not rounding
correctly for exact 0.5 values.
EDIT:
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. . . .
EDIT: Tue 2019.08.20