result of BigDecimal toFixed should be different from Number toFixed

[yukinotech]

In node or chrome（v8） , when the result of toFixed is rounded, the result is not accurate . because number is float

console.log((1.05).toFixed(1)) // 1.1
console.log((1.15).toFixed(1)) // 1.1
console.log((1.25).toFixed(1)) // 1.3
console.log((1.35).toFixed(1)) // 1.4
console.log((1.45).toFixed(1)) // 1.4
console.log((1.55).toFixed(1)) // 1.4
console.log((1.65).toFixed(1)) // 1.6
console.log((1.75).toFixed(1)) // 1.8
console.log((1.85).toFixed(1)) // 1.9
console.log((1.95).toFixed(1)) // 1.9

however , in BigDecimal ,we can claculate an exact value by roundMode

// default use `half up` roundMode
console.log((1.05m).toFixed(1)) // 1.1
console.log((1.15m).toFixed(1)) // 1.2
console.log((1.25m).toFixed(1)) // 1.3
console.log((1.35m).toFixed(1)) // 1.4
console.log((1.45m).toFixed(1)) // 1.5
console.log((1.55m).toFixed(1)) // 1.6
console.log((1.65m).toFixed(1)) // 1.7
console.log((1.75m).toFixed(1)) // 1.8
console.log((1.85m).toFixed(1)) // 1.9
console.log((1.95m).toFixed(1)) // 2.0

The same problem appeared in BigDecimal.prototype.toExponential

[Yaffle]

@yukinotech
1.05 in the source code is converted to 1.0500000000000000444089209850062616169452667236328125 floating point value, then Number#toFixed is applied;
Both algorithms are defined to work with exact mathematical value.

Well, there is a problem with Intl.NumberFormat, where they want to look at 1.0500000000000000444089209850062616169452667236328125 as the 1.05 and so do the "toRawFixed" differently, and the spec is still not defined well (see tc39/ecma402#128)