guest271314 at gmail.com (2019-03-10T17:39:32.820Z)
> So this would help with precision?
To an appreciable degree, yes, within 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
const i = 1234.567
Each digit has a formal name which developers can get and set, whether in
an array, object or number format.
Developers expect
i % 1 // .567
not
i % 1 // 0.5670000000000073
Where the initial number of digits following decimal, if any, is calculated, 0.5670000000000073 should not ever be output, as the code stops when 3 digits are calculated.
Represented as an array
[1,2,3,4,0.5,6,7]
any digit can be set, then converted back to a number.
arr[4] = arr[4] + .2 // [1,2,3,4,0.7,6,7]
Taking the procedure a step further, if arr[4] result is greater than 1 the calculation can be "carried" to then next digit in the fraction or integer part, which can then be converted back to a number with the "assurance" that the values in the array will be the precise values in the resulting number.
guest271314 at gmail.com (2019-03-10T17:34:57.292Z)
> So this would help with precision?
To an appreciable degree, yes, within 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
const i = 1234.567
Each digit has a formal name which developers can get and set, whether in
an array, object or number format.
Developers expect
i % 1 // .567
not
i % 1 // 0.5670000000000073
Where the initial number of digits following decimal, if any, is calculated, 0.5670000000000073 should not ever be output, as the code stops when 3 digits are calculated.
Represented as an array
[1,2,3,4,0.5,6,7]
any digit can be set, then converted back to a number.
arr[4] = arr[4] + .2 // [1,2,3,4,0.7,6,7]
Taking the procedure a step further, if arr[4] result is greater than 1 the calculation can be "carried" to then next digit in the fraction part, which can then be converted back to a number with the "assurance" that the values in the array will be the precise values in the resulting number.
guest271314 at gmail.com (2019-03-10T17:27:09.673Z)
> So this would help with precision?
To an appreciable degree, yes, within 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.
> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190310/8917c53d/attachment-0001.html>