On 2019-01-21 06:54, Ethan Resnick wrote:
if you input this in a browser debugger it will indeed respond with the
same 21 [sort of] significant digits
999999999999999900000
I'm pretty sure the 0s don't count as significant digits
<https://www.wikiwand.com/en/Significant_figures> (and, with floating point
numbers, it makes sense that they wouldn't).
Well, if you remove the trailing 0s you get an entirely different number.
That's pretty significant.
Note that this is the default ES serialization as well.
That's probably the origin of the 21 digit thing.
It MUST NOT be changed because then a coming IETF standard would break as well:
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-02#section-3.2.2.3
Anders
l this is probably best asked at https://github.com/tc39/ecma402, since it
seems to imply a potential spec bug.
Although my question was framed in terms of NumberFormat, I don't actually think this
is Ecma 402-specific. Specifically, I believe the limit started, or at least also
applies to, the Number.prototype.toPrecision
<https://www.ecma-international.org/ecma-262/6.0/#sec-number.prototype.toprecision>
API from Ecma 262 (where it is equally unexplained).
That's true for decimal values, but the limit of 21 would also include the
fractional portion of the double value as well, so would need more than 17, I
think?
My understanding of floating point encoding is that 17 digits will also cover
the fractional portion. The only case I can think of where 17 digits might not
be enough is if the number system is not base 10; e.g., a base 6 number system
would presumably require more digits. But, I don't see any such number systems
as output options in the NumberFormat API, and such localization concerns don't
really explain the limit in N.p.toPrecision linked above, which is definitely
dealing with base 10.
On Sun, Jan 20, 2019 at 4:48 PM Logan Smyth <[email protected]
<mailto:[email protected]>> wrote:
It does seem unclear why the limit is 21. Is that maybe the most you need
to uniquely stringify any double value?
> an only encode up to 17 significant decimal digits
That's true for decimal values, but the limit of 21 would also include the
fractional portion of the double value as well, so would need more than 17, I
think?
On Sun, Jan 20, 2019 at 1:18 PM Isiah Meadows <[email protected]
<mailto:[email protected]>> wrote:
I feel this is probably best asked at https://github.com/tc39/ecma402,
since it seems to imply a potential spec bug.
-----
Isiah Meadows
[email protected] <mailto:[email protected]>
www.isiahmeadows.com <http://www.isiahmeadows.com>
On Sun, Jan 20, 2019 at 2:31 PM Anders Rundgren <[email protected]
<mailto:[email protected]>> wrote:
On 2019-01-20 20:18, Ethan Resnick wrote:
> Hi,
>
> Apologies if es-discuss is the wrong venue for this; I've tried
first poring through the specs and asking online to no avail.
>
> My question is: why is the limit for the
`maximumSignificantDigits` option in the `NumberFormat` API set at 21? This seems
rather arbitrary — and especially odd to me given that, iiuc, all Numbers in JS,
as 64 bit floats, can only encode up to 17 significant decimal digits. Is this
some sort of weird historical artifact of something? Should the rationale be
documented anywhere?
I don't know for sure but if you input this in a browser debugger
it will indeed respond with the same 21 [sort of] significant digits
999999999999999900000
rgds,
Anders
>
> Thanks!
>
> Ethan
>
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
