> > This is not a problem at all, that's not a single time I needed to do > anything like that in any code I worked with, neither most of the > developers here, and I dare to assume that even you used such > algorithm only a few times in your career. That a lot more complex > problems that need our attention, don't providing any real world > examples (aside from "solving this simple algorithm problem") will get > you anywhere
Given an input number, get the _n_th integer or decimal. Neither Number nor Math provides a means to do that. This proposal does provide a template for a means to do that. On Tue, Mar 12, 2019 at 5:43 PM Augusto Moura <augusto.borg...@gmail.com> wrote: > > The proposal improves what is broken by not returning broken results > relevant to decimal numbers. The proposal allows users to get and set any > portion of a number using indexes of an array, which can then be converted > back to a number. > > This is not a problem at all, that's not a single time I needed to do > anything like that in any code I worked with, neither most of the > developers here, and I dare to assume that even you used such > algorithm only a few times in your career. That a lot more complex > problems that need our attention, don't providing any real world > examples (aside from "solving this simple algorithm problem") will get > you anywhere > > > If you are failing to interpret that as useful, that is your own issue. > You might as well state that Intl.NumberFormat.prototype.formatToParts does > not have any use. And further, JavaScript number implementation is fine > just the way that it is currently implemented, unless you decide that any > proposal is useful. > > > The proposal is asking you people who claim to be specification authors > to _name_ each element of the resulting array, for consistency, again, the > example > > > Number to array, array to number is just the first part of the > procedure. The part relevant to actually _naming_ the parts, for > disambiguation, is what propose here. If you are not interested, that is > fine. Do not necessarily need you to do anything. Will do for self as have > and continue to do independently, and name the discrete portions of the > number arbitrarily, without your input. > > I don't think you understood the motivation of this mailing list and > the TC39 committee, the discussions usually are for additions for the > ECMAScript language (usually native APIs, syntax and implementation > details), concept naming and conventions are NOT responsibility of > this community. I suggest the reading of the TC39 proposal document > [1] and some proposals as examples [2] > > At this point I'm just arguing with you for the sake of clarity to new > members that reach this thread > > [1]: https://tc39.github.io/process-document/ > [2]: https://github.com/tc39/proposals > > Em ter, 12 de mar de 2019 às 13:54, guest271314 > <guest271...@gmail.com> escreveu: > >> > >> That's the premise that I'm challenging. Why is it simpler, and how > does it, in any appreciable way, improve upon whatever you're asserting is > "broken"? > > > > > > The same way that Intl.NumberFormat.prototype.formatToParts does. Though > takes the concept one step further by spreading each digit to an array. If > the number has a decimal, the decimal portion is set at a single element of > an array. If the decimal begins with a 0, continue until the first non-zero > number is reached, include that number in the decimal portion within the > array, and the remainder of the decimal portion is spread to remainder of > array elements > > > > Example: > > > > var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5] > > arrayToNumber(n); // 100.00015 > > > > The proposal improves what is broken by not returning broken results > relevant to decimal numbers. The proposal allows users to get and set any > portion of a number using indexes of an array, which can then be converted > back to a number. > > > > If you are failing to interpret that as useful, that is your own issue. > You might as well state that Intl.NumberFormat.prototype.formatToParts does > not have any use. And further, JavaScript number implementation is fine > just the way that it is currently implemented, unless you decide that any > proposal is useful. > > > > The array format is a simple data structure. Can be converted to JSON; > can be extended to include a description of each digit that is a user gets > or sets; e.g., > > > > n[0].description // {digit: 1, place: 'hundreds', decimalSibling: > true, ...etc.} > > > >> With respect, your test cases confuse the issue more than they clarify. > Questions on how you'd use this structure aside (which are still > important), your test cases don't actually produce a structure in which > digits are accessible by nth index (e.g., the 0-grouping behavior). > > > > > > Not sure what you mean? What are you confused about relevant to the test > cases? The code at the OP includes 1) the original proof of concept; 2) > code by Stack Overflow user Shidersz which fixed two bugs in the original > code. Yes, the code at the OP does produce the expected result. > > > > You are misconstruing the proposal. The code already returns the > expected result. Do not ask for approval for anything. Just do and let the > aftermath settle to its own level. > > > > The proposal is asking you people who claim to be specification authors > to _name_ each element of the resulting array, for consistency, again, the > example > > > > var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5] > > > > as an array users obviously do not have additional data about the values > in the array. What do you call the 0 at index 1? What do you call the 5 at > index 4? > > > > Before incorporating the output into an object, similar to > Intl.NumberFormat.prototype.formatToParts - and including the original > array in the object, or Map - am asking for standardization of the names of > each digit in a _spread_ number in an array. > > > > Number to array, array to number is just the first part of the > procedure. The part relevant to actually _naming_ the parts, for > disambiguation, is what propose here. If you are not interested, that is > fine. Do not necessarily need you to do anything. Will do for self as have > and continue to do independently, and name the discrete portions of the > number arbitrarily, without your input. > > > > Again, if you do not gather that this proposal is similar to and extends > the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you > should try to use that feature, note that "integer" and "fraction" and > "minusSign" are possible return values at output, then lobby for the > feature to be removed from Ecma specification, for the same reasons that > you are citing at this proposal, which would then make your > > > >> premise that I'm challenging > > > > > > consistent. Otherwise, you have only offered standard western academic > conjecture, which can be set aside where an individual is not beholden to > or reliant on western academic conjecture to proceed with anything they > decide to. > > > >> With respect, > > > > > > "respect" is irrelevant to the proposal. Do not need or care about what > you consider "respect". You cannot offend this user. > > > > On Tue, Mar 12, 2019 at 3:46 PM Jeremy Martin <jmar...@gmail.com> wrote: > >>> > >>> The proposal seeks to standardize the naming conventions of number to > array and array to number, including decimals. > >> > >> > >> You're describing the hammer. When we ask for the motivation for your > proposal, we're trying to understand what you want to do with the hammer, > and that needs to be something more generalized than programmatically > recreating an interesting number sequence (and more explicitly stated than > whatever we are to infer from your test cases). > >> > >> In our repeated attempts to suss that out, this seems to be your > clearest description: > >> > >>> It is simpler to have the ability to add, subtract, divide, or > otherwise manipulate individual nth indexes of an integer or decimal > represented as an array of integers potentially containing one decimal than > trying to perform the same mathematical operations on a number in > JavaScript (essentially broken in JavaScript due to the floating-point > number issues). > >> > >> > >> That's the premise that I'm challenging. Why is it simpler, and how > does it, in any appreciable way, improve upon whatever you're asserting is > "broken"? As specified by your proposal, your input and output parameters > are Floats, which means that the precision limitations of floating point > numbers remain unaddressed. > >> > >>> All of the test cases used at the code which fixed the bugs in the > proof of concept at the original post output the expected result. > >> > >> > >> With respect, your test cases confuse the issue more than they clarify. > Questions on how you'd use this structure aside (which are still > important), your test cases don't actually produce a structure in which > digits are accessible by nth index (e.g., the 0-grouping behavior). > >> > >> On Tue, Mar 12, 2019 at 2:13 AM guest271314 <guest271...@gmail.com> > wrote: > >>>> > >>>> With respect, it's still not clear how you want to interact with the > array of values once you've destructured a Float into your array format. > >>>> > >>>> If all you have is an array of single-digit numbers that represent > the values in the tenths/hundredths/etc. positions of the source number, > how does this actually circumvent the challenges of representing Decimal > values that aren't exactly representable as a Float? > >>> > >>> > >>> It is not clear how your examples of adding specific values in > JavaScript are relevant to the proposal. > >>> > >>> All of the test cases used at the code which fixed the bugs in the > proof of concept at the original post output the expected result. > >>> > >>> If you have more test cases, number or decimal, to suggest for input > relevant to the code at the original proposal, number to array, array to > number, kindly post those tests cases listing input and expected output. > >>> > >>> The proposal does not seek to solve all JavaScript number issues. > >>> > >>> The proposal seeks to standardize the naming conventions of number to > array and array to number, including decimals. An array is the simplest > form of structured output. An object of key, value pairs (similar to > Intl.NumberFormat, with JavaScript numbers instead of strings) can also be > utilized for each of the digits of integer and decimal (fraction), if any. > >>> > >>> > >>> > >>> On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin <jmar...@gmail.com> > wrote: > >>>> > >>>> With respect, it's still not clear how you want to interact with the > array of values once you've destructured a Float into your array format. > >>>> > >>>> If all you have is an array of single-digit numbers that represent > the values in the tenths/hundredths/etc. positions of the source number, > how does this actually circumvent the challenges of representing Decimal > values that aren't exactly representable as a Float? > >>>> > >>>> To illustrate this challenge, let's use the classic example we've all > seen hundreds of times: > >>>> > >>>> > .1 + .2 > >>>> 0.30000000000000004 > >>>> > >>>> For a long time, all the reading I would do about why this produced a > weird result would sort of make sense and sort of confuse me. That is, I > could understand why 3/10ths isn't representable as a Float, but then I > would get confused by the fact that I could type `.3` into a REPL, and it > would actually work (??!): > >>>> > >>>> > .3 > >>>> 0.3 > >>>> > >>>> I mean, who's lying? How come `.3` works fine when I just type it > straight in, and `.1 + .3` works just fine, but there's just these specific > cases like `.1 + .2` where all of a sudden `.3` decides not to be > representable again? > >>>> > >>>> I admit this is conjecture, but maybe that's part of the confusion > motivating this proposal? And maybe the idea is that if we can break `.1` > and `.2` into some sort of an array structure (e.g., [0, 1] and [0, 2]), > then we can add the individual parts as integers (giving us something like > [0, 3]) which we can then just convert back into a single numeric value at > the end as 0.3, and voila, no 0.30000000000000004 shenanigans? > >>>> > >>>> The problem is that this all builds on a fundamental misunderstanding > of what's going. Let's revisit the basic example of entering a value into > the REPL: > >>>> > >>>> > .3 > >>>> 0.3 > >>>> > >>>> This, as I stated earlier, contributed greatly to my own hangups in > understanding what was going on here. What I personally didn't understand > was that the `0.3` value you see above isn't actually the Decimal value > 0.3. It's just a very close approximation of 0.3. (so close, in fact, that > 0.3 is the closest Decimal value that it can be rounded to, so that's what > gets emitted). > >>>> > >>>> So, going back to our earlier example, why do we get a different > output when we're dealing with the result of a mathematical operation, as > opposed to getting the same very close approximation of 0.3 that we get > when we simply type it into the REPL? > >>>> > >>>> > .1 + .2 > >>>> 0.30000000000000004 > >>>> > >>>> The answer lies in the fact that 0.1 and 0.2 also can't be > represented exactly as Floats. Just like we saw with 0.3, we can type them > into the REPL and see a value that looks the exact same being emitted back > at us: > >>>> > >>>> > .1 > >>>> 0.1 > >>>> > .2 > >>>> 0.2 > >>>> > >>>> ...but also like we saw with 0.3, they only look like accurate > representations. Once again, 0.1 and 0.2 are just the closest Decimal > values that the underlying Float values can be rounded to for display. > >>>> > >>>> This rounding behavior, then, is what causes us to get > 0.30000000000000004 when we add them together, because the slight rounding > error with 0.1 and the slight rounding error with 0.2 compound to result in > a Float that no longer rounds closer to 0.3, and instead closer to the > "wrong" Decimal value that we see emitted before. > >>>> > >>>> It's worth noting that this same behavior applies to, e.g., 0.1 + > 0.3, even though that looks like it produces the correct result of 0.4. In > reality, however, this is just a case where the rounding errors have the > effect of (almost) canceling each other out, such that the resulting Float > rounds closer to 0.4 than any other value for display purposes (despite > being only negligibly more accurate than our 0.30000000000000004 result > was). > >>>> > >>>> Ok, so why am I trying to explain all this? Because I'm trying to > illustrate why it sounds like this proposal doesn't actually solve the > problem that you want it to. Is it possible to standardize a system for > transformations and math operations like the following? > >>>> > >>>> const arg1 = numberToArray(0.1) // [0, 1] > >>>> const arg2 = numberToArray(0.2) // [0, 2] > >>>> > >>>> const arraySum = addArrayNumbers(arg1, arg2) // [0, 3] > >>>> > >>>> const result = arrayToNumber(arraySum) // 0.3 > >>>> > >>>> Sure, and at the very end, you actually get a value that looks right > (0.3, yay!). But it's still not actually 0.3. So what become the motivation > for this? You have a solution that, in terms of memory and CPU cycles, is > orders of magnitude more costly to calculate than `0.1 + 0.2` as a plain > JavaScript expression, and in return you get a result that is, at best, > infinitesimally more accurate than the alternative when carried all the way > out to the quadrillionths place or greater. > >>>> > >>>> Do you actually have a use case for mathematical operations that are > fault tolerant enough to represent Decimal values as Floats, but that fault > tolerance is sensitive to very, very specific rounding behavior at the > quadrillionths level? I can't even imagine what that use case would be. > >>>> > >>>> On Mon, Mar 11, 2019 at 10:06 AM guest271314 <guest271...@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. > >>>>> > >>>>> > >>>>> 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 nth 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 > >>>> > >>>> > >>>> > >>>> -- > >>>> Jeremy Martin > >>>> 661.312.3853 > >>>> @jmar777 / @j > >>>> > >> > >> > >> -- > >> Jeremy Martin > >> 661.312.3853 > >> @jmar777 / @j > >> > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > -- > Atenciosamente, > > Augusto Borges de Moura >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
