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
