Re: NumberFormat maxSignificantDigits Limit

2019-02-04 Thread Waldemar Horwat
There is precedence for using numbers around 20 for significant digit cutoffs in the spec. For example, if you look at how number tokens are parsed in the spec (§11.8.3.1), the implementation has the option to ignore significant digits after the 20th. That's not a bug; we did that

Re: NumberFormat maxSignificantDigits Limit

2019-01-26 Thread Ranando King
Here's a wikipedia link for what it's worth. https://en.wikipedia.org/wiki/Extended_precision Look at the *Working Range* section. On Sat, Jan 26, 2019 at 2:03 PM Ranando King wrote: > There's another possibility. C++ was the language of choice back then. It > had a type "long double", a

Re: NumberFormat maxSignificantDigits Limit

2019-01-26 Thread Ranando King
There's another possibility. C++ was the language of choice back then. It had a type "long double", a 80-bit extended double type. It was meant to match Intel's implementation of IEEE 754. This number format can be safely and reversibly converted back and forth with 21 significant digits. On Thu,

Re: NumberFormat maxSignificantDigits Limit

2019-01-24 Thread Isiah Meadows
For all here interested, you might want to follow this Twitter conversation I started. My theory is a subtle spec bug that copied the number instead of recalculating the formula. https://twitter.com/isiahmeadows1/status/108851744948878 - Isiah Meadows cont...@isiahmeadows.com

Re: NumberFormat maxSignificantDigits Limit

2019-01-23 Thread Anders Rundgren
On 2019-01-24 04:45, Ethan Resnick wrote: 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. This makes no sense to me. Yes, removing trailing 0s, and therefore changing the

Re: NumberFormat maxSignificantDigits Limit

2019-01-23 Thread Ethan Resnick
> > 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. > This makes no sense to me. Yes, removing trailing 0s, and therefore changing the magnitude of the number, changes its meaning. But

Re: NumberFormat maxSignificantDigits Limit

2019-01-21 Thread Anders Rundgren
On 2019-01-21 07:14, Carsten Bormann wrote: On Jan 21, 2019, at 07:03, Anders Rundgren wrote: coming IETF standard We don’t know that yet. Right, but it looks rather promising in addition to being verified to work on multiple platforms. The days of the Base64Url tyranny are numbered

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Anders Rundgren
This limit seems a bit strange though: console.log(new Intl.NumberFormat('en', { maximumFractionDigits: 20 }).format(-0.03)); Result: -0.0333 That's actually two digits less than produced by the default ES serialization. "maximumFractionDigits" is limited

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Carsten Bormann
On Jan 21, 2019, at 07:03, Anders Rundgren wrote: > > coming IETF standard We don’t know that yet. Grüße, Carsten ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Anders Rundgren
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 0 I'm pretty sure the 0s don't count as significant digits (and,

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Ethan Resnick
> > if you input this in a browser debugger it will indeed respond with the > same 21 [sort of] significant digits > 0 I'm pretty sure the 0s don't count as significant digits (and, with floating point numbers, it makes sense

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Logan Smyth
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

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Isiah Meadows
I feel this is probably best asked at https://github.com/tc39/ecma402, since it seems to imply a potential spec bug. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Sun, Jan 20, 2019 at 2:31 PM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2019-01-20 20:18,

Re: NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Anders Rundgren
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

NumberFormat maxSignificantDigits Limit

2019-01-20 Thread Ethan Resnick
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