>
> (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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190310/16c38067/attachment-0001.html>

> (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. Since the graph of using only the indexes of an array or string represented as a whole number and being a multiple of 9 is not linear (tl;dr How to improve efficiency of algorithm which generates next lexicographic permutation? https://stackoverflow.com/q/43290467)

    // graph 1
    0,9,81

    // graph 2
    abc 012 0
    acb 021 1 9
    bac 102 2 81
    bca 120 3 18
    cab 201 4 81
    cba 210 5 9

     /\/\
    /    \

finding the mathematical relationship between discrete permutations (as a whole number) requires graphing multiple decimal numbers in attempt to *find* an *approximate* numeric relationship between the numbers (e.g., the below was done by hand)

    ~~(128.625*9*1.074) // 1243
    ~~(128.625*9*1.144) // 1324

which can be described as *fuzzy-logic* graphing. In an array format the graphs can be finely tuned to adjust both 
   
    128.625

and

    1.074

through and beyond

    1.144

in parallel, or, for example, using several generator functions which maps the approximations closest to the criteria 
needed to get the precise multiple of 9 to get the *n*th permutation. With input "abcd" the procedure *can* be done by hand, with input of "abcdefghi" or >9 elements or digits (see 9erilous 9ermutations https://codegolf.stackexchange.com/q/175693)


> This pattern always holds, even when you start using more that 10 numbers, though the length of the sequence is 𝑛!−1 for 𝑛 numbers. Note that to use numbers above 0 to 9, we don't change to a different base, we just multiply the number by 10𝑥, e.g. [1,12,11]10=1∗102+12∗101+11∗100=231. 

of input (the value is ignored) the array format is much simpler, to keep track of, or graph the trial and error.

    

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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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}) => 
          // ideally conversion to String then back to Number should not be necessary in JavaScript ("cost" of calculating .length of a String)
          ({[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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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. Since the graph of using only the indexes of an array or string represented as a whole number and being a multiple of 9 is not linear (tl;dr How to improve efficiency of algorithm which generates next lexicographic permutation? https://stackoverflow.com/q/43290467)

    // graph 1
    0,9,81

    // graph 2
    abc 012 0
    acb 021 1 9
    bac 102 2 81
    bca 120 3 18
    cab 201 4 81
    cba 210 5 9

     /\/\
    /    \

finding the mathematical relationship between discrete permutations (as a whole number) requires graphing multiple decimal numbers in attempt to *find* an *approximate* numeric relationship between the numbers (e.g., the below was done by hand)

    ~~(128.625*9*1.074) // 1243
    ~~(128.625*9*1.144) // 1324

which is akin to fuzzy-logic graphing. In an array format the graphs can be finely tuned to adjust both 
   
    128.625

and

    1.074

through and beyond

    1.144

in parallel, or, for example, using several generator functions which maps the approximations closest to the criteria 
needed to get the precise multiple of 9 to get the *n*th permutation. With input "abcd" the procedure *can* be done by hand, with input of "abcdefghi" or >9 elements or digits (see 9erilous 9ermutations https://codegolf.stackexchange.com/q/175693)


> This pattern always holds, even when you start using more that 10 numbers, though the length of the sequence is 𝑛!−1 for 𝑛 numbers. Note that to use numbers above 0 to 9, we don't change to a different base, we just multiply the number by 10𝑥, e.g. [1,12,11]10=1∗102+12∗101+11∗100=231. 

of input (the value is ignored) the array format is much simpler, to keep track of, or graph the trial and error.

    

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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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}) => 
          // ideally conversion to String then back to Number should not be necessary in JavaScript ("cost" of calculating .length of a String)
          ({[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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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. Since the graph of using only the indexes of an array or string represented as a whole number and being a multiple of 9 is not linear (tl;dr How to improve efficiency of algorithm which generates next lexicographic permutation? https://stackoverflow.com/q/43290467)

    // graph 1
    0,9,81

    // graph 2
    abc 012 0
    acb 021 1 9
    bac 102 2 81
    bca 120 3 18
    cab 201 4 81
    cba 210 5 9

     /\/\
    /    \

finding the mathematical relationship between discrete permutations (as a whole number) requires graphing multiple decimal numbers in attempt to *find* an *approximate* numeric relationship between the numbers (e.g., the below was done by hand)

    ~~(128.625*9*1.074) // 1243
    ~~(128.625*9*1.144) // 1324

which is akin to fuzzy-logic graphing. In an array format the graphs can be finely tuned to adjust both 
   
    128.625

and

    1.074

through and beyond

    1.144

in parallel, or, for example, using several generator functions which maps the approximations closest to the criteria 
needed to get the precise multiple of 9 to get the *n*th permutation. With input "abcd" the procedure *can* be done by hand, with input of "abcdefghi" or >9 elements or digits of input (the value is ignored) the array format is much simpler, to keep track of, or graph the trial and error.

    

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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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}) => 
          // ideally conversion to String then back to Number should not be necessary in JavaScript ("cost" of calculating .length of a String)
          ({[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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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. Since the graph of using only the indexes of an array or string represented as a whole number and being a multiple of 9 is not linear (tl;dr https://stackoverflow.com/q/43290467)

    // graph 1
    0,9,81

    // graph 2
    abc 012 0
    acb 021 1 9
    bac 102 2 81
    bca 120 3 18
    cab 201 4 81
    cba 210 5 9

     /\/\
    /    \

finding the mathematical relationship between discrete permutations (as a whole number) requires graphing multiple decimal numbers in attempt to *find* an *approximate* numeric relationship between the numbers (e.g., the below was done by hand)

    ~~(128.625*9*1.074) // 1243
    ~~(128.625*9*1.144) // 1324

which is akin to fuzzy-logic graphing. In an array format the graphs can be finely tuned to adjust both 
   
    128.625

and

    1.074

through and beyond

    1.144

in parallel, or, for example, using several generator functions which maps the approximations closest to the criteria 
needed to get the precise multiple of 9 to get the *n*th permutation. With input "abcd" the procedure *can* be done by hand, with input of "abcdefghi" or >9 elements or digits of input (the value is ignored) the array format is much simpler, to keep track of, or graph the trial and error.

    

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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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}) => 
          // ideally conversion to String then back to Number should not be necessary in JavaScript ("cost" of calculating .length of a String)
          ({[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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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}) => 
          // ideally conversion to String then back to Number should not be necessary in JavaScript ("cost" of calculating .length of a String)
          ({[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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value. 

Conversion of integer or decimal to array and array to integer or decimal allows developers to *get* **and** *set* any index or element of the array, which then can be converted back to a number comprising all of its parts - without conversion to String during the procedure.

> (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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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?

The use of Math.trunc and remainder operator are getters, if the code portion of this proposal is reached, beyond standardization of the naming of getting certain portions of integers and arrays, developers should be able to use the same or similar methods to get *and* set the value of any digit of the integer or decimal, not only get the value.

> (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, most of the work has already been done. Alternatively, Intl.NumberFormat can be extended or adjusted to return numbers in an array instead of strings; 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?

> (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, most of the work has already been done. Alternatively, Intl.NumberFormat 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?

> (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?

> (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?

> (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?