>
> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,
...etc.}

With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).


Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in
the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature to be removed from Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your

premise that I'm challenging


consistent. Otherwise, you have only offered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to.

With respect,


"respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

On Tue, Mar 12, 2019 at 3:46 PM Jeremy Martin <jmar777 at gmail.com> wrote:

> The proposal seeks to standardize the naming conventions of number to
>> array and array to number, including decimals.
>
>
> You're describing the hammer. When we ask for the motivation for your
> proposal, we're trying to understand *what you want to do with the hammer*,
> and that needs to be something more generalized than programmatically
> recreating an interesting number sequence (and more explicitly stated than
> whatever we are to infer from your test cases).
>
> In our repeated attempts to suss that out, this seems to be your clearest
> description:
>
> It is simpler to have the ability to add, subtract, divide, or otherwise
>> manipulate individual nth indexes of an integer or decimal represented as
>> an array of integers potentially containing one decimal than trying to
>> perform the same mathematical operations on a number in JavaScript
>> (essentially broken in JavaScript due to the floating-point number issues).
>
>
> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"? As specified by your proposal, your input and output parameters
> are Floats, which means that the precision limitations of floating point
> numbers remain unaddressed.
>
> All of the test cases used at the code which fixed the bugs in the proof
>> of concept at the original post output the expected result.
>
>
> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).
>
> On Tue, Mar 12, 2019 at 2:13 AM guest271314 <guest271314 at gmail.com> wrote:
>
>> With respect, it's still not clear how you want to interact with the
>>> array of values once you've destructured a Float into your array format.
>>
>> If all you have is an array of single-digit numbers that represent the
>>> values in the tenths/hundredths/etc. positions of the source number, how
>>> does this actually circumvent the challenges of representing Decimal values
>>> that aren't exactly representable as a Float?
>>
>>
>> It is not clear how your examples of adding specific values in JavaScript
>> are relevant to the proposal.
>>
>> All of the test cases used at the code which fixed the bugs in the proof
>> of concept at the original post output the expected result.
>>
>> If you have more test cases, number or decimal, to suggest for input
>> relevant to the code at the original proposal, number to array, array to
>> number, kindly post those tests cases listing input and expected output.
>>
>> The proposal does not seek to solve all JavaScript number issues.
>>
>> The proposal seeks to standardize the naming conventions of number to
>> array and array to number, including decimals. An array is the simplest
>> form of structured output. An object of key, value pairs (similar to
>> Intl.NumberFormat, with JavaScript numbers instead of strings) can also be
>> utilized for each of the digits of integer and decimal (fraction), if any.
>>
>>
>>
>> On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin <jmar777 at gmail.com> wrote:
>>
>>> With respect, it's still not clear how you want to interact with the
>>> array of values once you've destructured a Float into your array format.
>>>
>>> If all you have is an array of single-digit numbers that represent the
>>> values in the tenths/hundredths/etc. positions of the source number, how
>>> does this actually circumvent the challenges of representing Decimal values
>>> that aren't exactly representable as a Float?
>>>
>>> To illustrate this challenge, let's use the classic example we've all
>>> seen hundreds of times:
>>>
>>> > .1 + .2
>>> 0.30000000000000004
>>>
>>> For a long time, all the reading I would do about *why* this produced a
>>> weird result would *sort* of make sense and *sort* of confuse me. That
>>> is, I could understand *why* 3/10ths isn't representable as a Float,
>>> but then I would get confused by the fact that I could type `.3` into a
>>> REPL, and it would *actually work *(??!):
>>>
>>> > .3
>>> 0.3
>>>
>>> I mean, who's lying? How come `.3` works fine when I just type it
>>> straight in, and `.1 + .3` works just fine, but there's just these
>>> specific cases like `.1 + .2` where all of a sudden `.3` decides not to
>>> be representable again?
>>>
>>> I admit this is conjecture, but maybe that's part of the confusion
>>> motivating this proposal? And maybe the idea is that if we can break `.1`
>>> and `.2` into some sort of an array structure (e.g., [0, 1] and [0, 2]), then
>>> we can add the individual parts as integers (giving us something like [0,
>>> 3]) which we can then just convert back into a single numeric value at
>>> the end as 0.3, and voila, no 0.30000000000000004 shenanigans?
>>>
>>> The problem is that this all builds on a fundamental misunderstanding of
>>> what's going. Let's revisit the basic example of entering a value into the
>>> REPL:
>>>
>>> > .3
>>> 0.3
>>>
>>> This, as I stated earlier, contributed greatly to my own hangups in
>>> understanding what was going on here. What I personally didn't understand
>>> was that the `0.3` value you see above isn't actually the *Decimal*
>>> value 0.3. It's just a *very* close approximation of 0.3. (so close, in
>>> fact, that 0.3 is the *closest* Decimal value that it can be rounded
>>> to, so that's what gets emitted).
>>>
>>> So, going back to our earlier example, why do we get a *different*
>>> output when we're dealing with the result of a mathematical operation, as
>>> opposed to getting the *same* very close approximation of 0.3 that we
>>> get when we simply type it into the REPL?
>>>
>>> > .1 + .2
>>> 0.30000000000000004
>>>
>>> The answer lies in the fact that 0.1 and 0.2 *also* can't be
>>> represented exactly as Floats. Just like we saw with 0.3, we can type them
>>> into the REPL and see a value that looks the exact same being emitted back
>>> at us:
>>>
>>> > .1
>>> 0.1
>>> > .2
>>> 0.2
>>>
>>> ...but also like we saw with 0.3, they only *look* like accurate
>>> representations. Once again, 0.1 and 0.2 are just the closest Decimal
>>> values that the underlying Float values can be rounded to for display.
>>>
>>> This rounding behavior, then, is what causes us to get
>>> 0.30000000000000004 when we add them together, because the *slight*
>>> rounding error with 0.1 and the *slight* rounding error with 0.2
>>> compound to result in a Float that no longer rounds closer to 0.3, and
>>> instead closer to the "wrong" Decimal value that we see emitted before.
>>>
>>> It's worth noting that this same behavior applies to, e.g., 0.1 + 0.3, even
>>> though that *looks* like it produces the correct result of 0.4. In
>>> reality, however, this is just a case where the rounding errors have the
>>> effect of (almost) canceling each other out, such that the resulting Float
>>> rounds closer to 0.4 than any other value for display purposes (despite
>>> being only negligibly more accurate than our 0.30000000000000004 result
>>> was).
>>>
>>> Ok, so why am I trying to explain all this? Because I'm trying to
>>> illustrate why it sounds like this proposal doesn't actually solve the
>>> problem that you want it to. Is it possible to standardize a system for
>>> transformations and math operations like the following?
>>>
>>>   const arg1 = numberToArray(0.1) // [0, 1]
>>>   const arg2 = numberToArray(0.2) // [0, 2]
>>>
>>>   const arraySum = addArrayNumbers(arg1, arg2) // [0, 3]
>>>
>>>   const result = arrayToNumber(arraySum) // 0.3
>>>
>>> Sure, and at the very end, you actually get a value that *looks* right (
>>> 0.3, yay!). But *it's still not actually 0.3.* So what become the
>>> motivation for this? You have a solution that, in terms of memory and CPU
>>> cycles, is orders of magnitude more costly to calculate than `0.1 + 0.2` as
>>> a plain JavaScript expression, and in return you get a result that is, *at
>>> best*, infinitesimally more accurate than the alternative when carried
>>> all the way out to the quadrillionths place or greater.
>>>
>>> Do you actually have a use case for mathematical operations that are
>>> fault tolerant enough to represent Decimal values as Floats, but that fault
>>> tolerance is sensitive to very, very specific rounding behavior at the
>>> quadrillionths level? I can't even imagine what that use case would be.
>>>
>>> On Mon, Mar 11, 2019 at 10:06 AM guest271314 <guest271314 at gmail.com>
>>> wrote:
>>>
>>>> JS numbers are specified to be in terms of IEEE-754 doubles, so tenths,
>>>>> hundredths, and so on cannot be precisely represented. [1] So there is no
>>>>> way to increase precision here beyond the above that Tab showed, assuming
>>>>> each of those operations are accurate to the bit.
>>>>
>>>>
>>>> Not sure what the message is trying to convey?  The code at the first
>>>> post already overcomes the issue of
>>>>
>>>>     i % 1 // 0.5670000000000073
>>>>
>>>> described by Tab. All of the input numbers are converted to array then
>>>> back to number without losing any precision or adding more numbers to the
>>>> input.
>>>>
>>>> The proposal suggests that each discrete digit of any number a user can
>>>> get and set and be clearly defined with a consistent name, or reference.
>>>> Converting the number to an array is a simple means of processing each
>>>> digit independently.
>>>>
>>>> On Mon, Mar 11, 2019 at 10:41 AM Isiah Meadows <isiahmeadows at gmail.com>
>>>> wrote:
>>>>
>>>>> JS numbers are specified to be in terms of IEEE-754 doubles, so
>>>>> tenths, hundredths, and so on cannot be precisely represented. [1] So there
>>>>> is no way to increase precision here beyond the above that Tab showed,
>>>>> assuming each of those operations are accurate to the bit.
>>>>>
>>>>> [1]:
>>>>> https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/
>>>>> On Sun, Mar 10, 2019 at 13:26 guest271314 <guest271314 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So this would help with precision?
>>>>>>
>>>>>>
>>>>>> To an appreciable degree, yes, without the scope of JavaScript
>>>>>> floating-point number implementation.
>>>>>>
>>>>>> The gist of the proposal is to formalize, standardize, or whatever
>>>>>> term specification writers want to use, the *naming* of each method or
>>>>>> operation which can get and set each discrete digit of a number - without
>>>>>> using String methods.
>>>>>>
>>>>>> For input
>>>>>>
>>>>>>     1234.567
>>>>>>
>>>>>> Each digit has a formal name which developers can get and set,
>>>>>> whether in an array, object or number format.
>>>>>>
>>>>>> On Sun, Mar 10, 2019 at 5:17 PM Michael Theriot <
>>>>>> michael.lee.theriot at gmail.com> wrote:
>>>>>>
>>>>>>> So this would help with precision?
>>>>>>>
>>>>>>> On Sunday, March 10, 2019, guest271314 <guest271314 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> (If you really wanted this as an integer, it's not well-founded;
>>>>>>>>> .567
>>>>>>>>> isn't exactly representable as a double, so JS doesn't know that
>>>>>>>>> you
>>>>>>>>> "meant" it to have only three digits after the decimal point, and
>>>>>>>>> thus
>>>>>>>>> want 567 as the answer. You'll instead get some very very large
>>>>>>>>> integer that *starts with* 567, followed by a bunch of zeros,
>>>>>>>>> followed
>>>>>>>>> by some randomish digits at the end.)
>>>>>>>>
>>>>>>>>
>>>>>>>> The code at the first post solves that problem.
>>>>>>>>
>>>>>>>> But the question is still "what would someone use this information
>>>>>>>>> for?"
>>>>>>>>
>>>>>>>>
>>>>>>>> That question has been answered several times in the posts above.
>>>>>>>> This users' motivation was and is the ability to manipulate JavaScript
>>>>>>>> floating-point numbers  (which could be considered "broken", as you
>>>>>>>> described above) in order to solve mathematical problems (in this case,
>>>>>>>> directly calculating the *n*th lexicographic permutation) with the
>>>>>>>> number or decimal being represented as an array, without having to be
>>>>>>>> concerned with not getting the same value when the array is converted back
>>>>>>>> to a number.
>>>>>>>>
>>>>>>>> Felipe Nascimento de Moura mentioned several other applications.
>>>>>>>>
>>>>>>>> The work has already been done. This proposal is essentially to
>>>>>>>> standardize the naming conventions. Whether a Number method is used
>>>>>>>>
>>>>>>>>     i.getTensMethod
>>>>>>>>
>>>>>>>> or an array is used
>>>>>>>>
>>>>>>>>    arr["integer"] // 1234
>>>>>>>>
>>>>>>>> or an object where values are arrays is used
>>>>>>>>
>>>>>>>>     o["fraction"] // .567
>>>>>>>>
>>>>>>>> Having mentioned Intl.NumberFormat earlier in the thread, if the
>>>>>>>> issue devoting resources to a *new *proposal, Intl.NumberFormate
>>>>>>>> can be extended; e.g. a rough draft in code
>>>>>>>>
>>>>>>>>     function formatNumberParts(args) {
>>>>>>>>       return Object.assign({sign:0, fraction:[0], integer:[0]},
>>>>>>>> ...args.filter(({type}) => type === "integer" || type === "fraction" ||
>>>>>>>> type === "minusSign").map(({type, value}) => ({[type === "minusSign" ?
>>>>>>>> "sign" : type]: type !== "minusSign" ? [...value].map(Number) : -1})));
>>>>>>>>     }
>>>>>>>>
>>>>>>>>     let number = -123;
>>>>>>>>
>>>>>>>>     let formatter = new Intl.NumberFormat('en-US');
>>>>>>>>
>>>>>>>>     let res = formatter.formatToParts(number);
>>>>>>>>
>>>>>>>>     formatNumberParts(res);
>>>>>>>>
>>>>>>>> If the concern is that the proposal would not be useful, consider
>>>>>>>> what you would *name* various uses of Math.trunc and remainder
>>>>>>>> operator used at your message?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Mar 10, 2019 at 3:58 PM Tab Atkins Jr. <
>>>>>>>> jackalmage at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura
>>>>>>>>> <felipenmoura at gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> > Personally, I don't think it would be THAT useful...
>>>>>>>>> > but...I think there is something behind this proposal that makes
>>>>>>>>> sense.
>>>>>>>>> >
>>>>>>>>> > I do believe it could be useful for developers to have an easier
>>>>>>>>> access to number parts or characteristics.
>>>>>>>>> > Perhaps something like:
>>>>>>>>> >
>>>>>>>>> > const i = 1234.567;
>>>>>>>>>
>>>>>>>>> Can you provide a scenario in which these would do something
>>>>>>>>> useful,
>>>>>>>>> such that it would be worth adding them over just using the math
>>>>>>>>> operations that already exist?
>>>>>>>>>
>>>>>>>>> > console.log( i.float ); // 567
>>>>>>>>>
>>>>>>>>> i % 1
>>>>>>>>>
>>>>>>>>> (If you really wanted this as an integer, it's not well-founded;
>>>>>>>>> .567
>>>>>>>>> isn't exactly representable as a double, so JS doesn't know that
>>>>>>>>> you
>>>>>>>>> "meant" it to have only three digits after the decimal point, and
>>>>>>>>> thus
>>>>>>>>> want 567 as the answer. You'll instead get some very very large
>>>>>>>>> integer that *starts with* 567, followed by a bunch of zeros,
>>>>>>>>> followed
>>>>>>>>> by some randomish digits at the end.)
>>>>>>>>>
>>>>>>>>> > console.log( i.abs ); // 1234
>>>>>>>>>
>>>>>>>>> Math.trunc(i)
>>>>>>>>>
>>>>>>>>> > console.log( i.thousands ); // 1
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 1000)
>>>>>>>>>
>>>>>>>>> > console.log( i.million ); // 0
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 1e6)
>>>>>>>>>
>>>>>>>>> > console.log( i.hundred ); // 2
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 100) % 10
>>>>>>>>>
>>>>>>>>> > console.log( i.hundreds ); // 12
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 100)
>>>>>>>>>
>>>>>>>>> > console.log( i.ten ); // 2
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 10) % 10
>>>>>>>>>
>>>>>>>>> > console.log( i.tens ); // 123
>>>>>>>>>
>>>>>>>>> Math.trunc(i / 10)
>>>>>>>>>
>>>>>>>>> > console.log( i.tenth ); // 5
>>>>>>>>>
>>>>>>>>> Math.trunc(i % 1 * 10) % 10
>>>>>>>>>
>>>>>>>>> > console.log( i.tenths ); // 5
>>>>>>>>>
>>>>>>>>> Math.trunc(i % 1 * 10)
>>>>>>>>>
>>>>>>>>> > console.log( i.hundredth ); // 6
>>>>>>>>>
>>>>>>>>> Math.trunc(i % 1 * 100) % 10
>>>>>>>>>
>>>>>>>>> > console.log( i.hundredths ); // 56
>>>>>>>>>
>>>>>>>>> Math.trunc(i % 1 * 100)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Some of these are easy to remember and use; others take some
>>>>>>>>> thinking
>>>>>>>>> to deploy. But the question is still "what would someone use this
>>>>>>>>> information for?", such that the benefit to developers is worth the
>>>>>>>>> cost to all parties involved (spec writers, implementors, testers,
>>>>>>>>> and
>>>>>>>>> then developers having to navigate a larger stdlib).
>>>>>>>>>
>>>>>>>>> ~TJ
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>>>
>>>
>
> --
> Jeremy Martin
> 661.312.3853
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190312/d551558c/attachment-0001.html>

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array - as a JavaScript number not as a JavaScript String.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).

FYI "respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature Intl.NumberFormat.prototype.formatToParts to be removed from tc39/Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your statement

> That's the premise that I'm challenging.


_consistent_. Otherwise, you have only proffered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to do.

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array - as a JavaScript number not as a JavaScript String.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).

FYI "respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature Intl.NumberFormat.prototype.formatToParts to be removed from tc39/Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your statement

> premise that I'm challenging


_consistent_. Otherwise, you have only proffered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to do.

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array - as a JavaScript number not as a JavaScript String.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).

FYI "respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature Intl.NumberFormat.prototype.formatToParts to be removed from tc39/Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your statement

> premise that I'm challenging


_consistent_. Otherwise, you have only proffered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to.

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).

FYI "respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature Intl.NumberFormat.prototype.formatToParts to be removed from tc39/Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your statement

> premise that I'm challenging


_consistent_. Otherwise, you have only proffered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to.

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).

FYI "respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.

Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature to be removed from tc39/Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your

> premise that I'm challenging


consistent. Otherwise, you have only offered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to.

> That's the premise that I'm challenging. Why is it simpler, and how does
> it, *in any appreciable way*, improve upon whatever you're asserting is
> "broken"?


The same way that Intl.NumberFormat.prototype.formatToParts does. Though
takes the concept one step further by *spreading* each digit to an array.
If the number has a decimal, the decimal portion is set at a single element
of an array. If the decimal begins with a 0, continue until the first
non-zero number is reached, include that number in the decimal portion
within the array, and the remainder of the decimal portion is spread to
remainder of array elements

Example:

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
    arrayToNumber(n); // 100.00015

The proposal improves what is broken by not returning broken results
relevant to decimal numbers. The proposal allows users to get and set any
portion of a number using indexes of an array, which can then be converted
back to a number.

If you are failing to interpret that as useful, that is your own issue. You
might as well state that Intl.NumberFormat.prototype.formatToParts does not
have any use. And further, JavaScript number implementation is fine just
the way that it is currently implemented, unless *you *decide that any
proposal is useful.

The array format is a simple data structure. Can be converted to JSON; can
be extended to include a description of each digit that is a user gets or
sets; e.g.,

    n[0].description // {digit: 1, place: 'hundreds', decimalSibling: true,...etc.}

> With respect, your test cases confuse the issue more than they clarify.
> Questions on how you'd use this structure aside (which are still
> important), your test cases *don't actually produce a structure in which
> digits are accessible by nth index* (e.g., the 0-grouping behavior).


Not sure what you mean? What are you confused about relevant to the test
cases? The code at the OP includes 1) the original proof of concept; 2)
code by  Stack Overflow user Shidersz
<https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs in

the original code. Yes, the code at the OP does produce the expected result.

You are misconstruing the proposal. The code already returns the expected
result. Do not ask for approval for anything. Just do and let the aftermath
settle to its own level.

The proposal is asking you people who claim to be specification authors to
_name_ each element of the resulting array, for consistency, again, the
example

    var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]

as an array users obviously do not have additional data about the values in
the array. What do you call the 0 at index 1? What do you call the 5 at
index 4?

Before incorporating the output into an object, similar to
Intl.NumberFormat.prototype.formatToParts - and including the original
array in the object, or Map - am asking for standardization of the names of
each digit in a _spread_ number in an array.

Number to array, array to number is just the first part of the procedure.
The part relevant to actually _naming_ the parts, for disambiguation, is
what propose here. If you are not interested, that is fine. Do not
necessarily need you to do anything. Will do for self as have and continue
to do independently, and name the discrete portions of the number
arbitrarily, without your input.

Again, if you do not gather that this proposal is similar to and extends
the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
should try to use that feature, note that "integer" and "fraction" and
"minusSign" are possible return values at output, then lobby for the
feature to be removed from Ecma specification, for the same reasons that
you are citing at this proposal, which would then make your

premise that I'm challenging


consistent. Otherwise, you have only offered standard western academic
conjecture, which can be set aside where an individual is not beholden to
or reliant on western academic conjecture to proceed with anything they
decide to.

With respect,


"respect" is irrelevant to the proposal. Do not need or care about what you
consider "respect". You cannot offend this user.