NumberFormat maxSignificantDigits Limit

Ethan Resnick ethan.resnick at gmail.com
Mon Jan 21 05:54:13 UTC 2019


>
> 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).

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 <loganfsmyth at gmail.com> 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 <isiahmeadows at gmail.com>
> 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
>> contact at isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Sun, Jan 20, 2019 at 2:31 PM Anders Rundgren <
>> anders.rundgren.net at gmail.com> 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
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190121/15861d10/attachment.html>


More information about the es-discuss mailing list