>
> 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 <isiahmead...@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 <guest271...@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.ther...@gmail.com> wrote:
>>
>>> So this would help with precision?
>>>
>>> On Sunday, March 10, 2019, guest271314 <guest271...@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. <jackalm...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura
>>>>> <felipenmo...@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@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
