Number of significant figures displayed when converting floats to base 5 with (float).toString(5) differs from other engines

[PeterW5]

Tested with the following:

(0.88).toString(5)
(1.88).toString(5)
(10.88).toString(5)

and the results were:

0.420000000000000000000004
1.41444444444444444444443
20.4200000000000000000001

The result for (1.88).toString(5) seems to be incorrect. Was expecting something closer to 1.42

[bterlson]

λ eshost -e "(1.88).toString(5)" --coalesce
#### d8, d8 harmony
1.4144444444444444444444333104231304012124202243132001220042133342211230124431042000101001310231344121433102220300300112230100220043122323130221403311220301234310204204421010331220310444443122341442001234022230433400111104114042404340014103440120320404303202111340422401121111402231044302103220123314422330322211113413112031221122232111204042202343142214244204414322202442430342240241200340014114242240114213320304430102310222212430001023220112143134240144031021133043223141434143114313012042231210424020200244423104040300144444401340230110341212341041403443222304033442134121420200020224223103430342133413123013003002443231421412422221404341424241220012324243040230003014102424121123132411330422121341342132031130023313233204204343004013140343104223144201320233341332034324232011120333014001410013440301413234144404424401301203332024044304314102113004341102404421403311221341142220011244012321320323410230302424141400312223144202111123202342041330431200420113023023424010211044130204113244212244132142202330032241031122213431313024044340210332303203244411232042234221040110013201204034402144441023423

#### chakra, chakra-es6, chakra-experimental
1.41444444444444444444443

#### sm, jsc
1.42

Looks like our results are half-way between v8 and jsc/sm. I haven't consulted the spec yet.

[dilijev]

1.4144444444444444444444333104231304012124202243132001220042133342211230124431042000101001310231344121433102220300300112230100220043122323130221403311220301234310204204421010331220310444443122341442001234022230433400111104114042404340014103440120320404303202111340422401121111402231044302103220123314422330322211113413112031221122232111204042202343142214244204414322202442430342240241200340014114242240114213320304430102310222212430001023220112143134240144031021133043223141434143114313012042231210424020200244423104040300144444401340230110341212341041403443222304033442134121420200020224223103430342133413123013003002443231421412422221404341424241220012324243040230003014102424121123132411330422121341342132031130023313233204204343004013140343104223144201320233341332034324232011120333014001410013440301413234144404424401301203332024044304314102113004341102404421403311221341142220011244012321320323410230302424141400312223144202111123202342041330431200420113023023424010211044130204113244212244132142202330032241031122213431313024044340210332303203244411232042234221040110013201204034402144441023423

Dat precision tho

[dilijev]

@PeterW5

Was expecting something closer to 1.42

In base 5, 1.4144...43 is very close to 1.42 (like base 10 1.999...98 is very close to 2.0) -- it looks like this is simply a matter of sig-figs and rounding.

[agarwal-sandeep]

@bterlson @dilijev is there a conformance issue here? seems like all engine behaves differently.

[dilijev]

It looks like d8 has updated their rounding behavior:

>eshost --tags jsvu -h ch-master-latest -ise "(1.88).toString(5)"
## Source
print((1.88).toString(5))

#### ch-master-latest, jsvu-ch
1.41444444444444444444443

#### jsvu-d8, jsvu-jsc, jsvu-sm
1.42

[MSLaguana]

It does look like our rounding behavior differs from other engines:

## Source
print(new Array(15).join('x').split('x').map((_,i) => (i+2) + ' ' + 9.090909090909092.toString(i+2)).join('\n'))

#### SpiderMonkey, V8 --harmony, JavascriptCore
2 1001.0001011101000101110100010111010001011101000101111
3 100.0021100211002110021100211002111
4 21.0113101131011310113101132
5 14.021140211402114021141
6 13.0313452421031345243
7 12.043116235504311625
8 11.05642721350564274
9 10.0732407324073242
10 9.090909090909092
11 9.1
12 9.11111111111112
13 9.12495ba837125
14 9.13b6513b6513c
15 9.156c4156c4158
16 9.1745d1745d178

#### Chakra
2 1001.0001011101000101110100010111010001011101000101111
3 100.0021100211002110021100211002110
4 21.0113101131011310113101132
5 14.0211402114021140211404
6 13.03134524210313452424
7 12.043116235504311625
8 11.05642721350564274
9 10.0732407324073242
10 9.090909090909091
11 9.1000000000000034
12 9.111111111111121
13 9.12495ba837124c8
14 9.13b6513b6513c1
15 9.156c4156c41585
16 9.1745d1745d178

For powers of two where there is no rounding necessary we do the same thing as the others, but for other bases we often differ. I initially thought that we were rounding down rather than up in these cases, but that's not always true, for example using base 11 above.

In fact, it somewhat looks like for bases up to 10 we are rounding down when others round up, and for bases greater than 10 we are displaying more digits / not rounding when others do.

[IrinaYatsenko]

I do see discrepancies in string representation between Chrome and SpiderMonkey (though not as big ones as between Chrome and Chakra). Tuned our algorithm a little bit so the result matches Chrome's more closely.