This bug was reported via nashorn-dev http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005142.html Email content below for reference: The implementation of Number.prototype.toFixed seems to be wrong in two cases. Can you confirm this, and/or report it on an issue tracker? Observed behaviour: > $ jjs -version > nashorn 1.8.0_60 > jjs> 0.5.toFixed() > 0 > jjs> -0.5.toFixed() > 0 Expected behaviour: The two results should be 1 and -1 respectively. I expect this behaviour because that is how I interpret ES5 and ES6 specifications for Number.prototype.toFixed, and because that is the behaviour that I can observe in Chrome and Firefox. Extra comments on possible cause of bug: The interesting part of the ES6 specification is 20.1.3.3 - 10. - a.: > Let n be an integer for which the exact mathematical value of n / 10^f ��� x is as close to zero as possible. If there are two such n, pick the larger n. In the case of `0.5.toFixed()` the expression above becomes: > n / 10^0 - 0.5 = n / 1 - 0.5 = n - 0.5 which solves to `n = 0` or `n = 1`. It seems that Nashorn picks the `n = 0` case instead of the `n = 1` case. --- Esben Andreasen ------------------- His interpretation seems right. See spec. section: https://es5.github.io/#x15.7.4.5 Step 8 Else, x < 1021 Let n be an integer for which the exact mathematical value of n �� 10f ��� x is as close to zero as possible. If there are two such n, pick the larger n.
|