Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)

Isiah Meadows isiahmeadows at gmail.com
Mon Mar 11 10:41:31 UTC 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190311/12d53b75/attachment.html>


More information about the es-discuss mailing list