> What part of the proposal, in your view, did not read "it'd be nice if ..." > number to array <--> array to number specification and standardization?
I think you missed my point in the first sentence. I'm saying the first thing on your mind when creating proposals *shouldn't* be "it'd be nice if ...". Please re-read that first sentence and you'll get what I'm saying. > Not sure what you mean by "toy problems"? Do you mean only concepts that meet > *your* "toy" interests? Scale is irrelevant. The real world problem is > standardization of number to array, array to number conversion in JavaScript. 1. Scale *is* mostly irrelevant here, even in my criticism. The only requirement here is that it's in code you'd actually write when building something. Code golf challenges aren't sufficient, since JS doesn't optimize for that. It needs to be something genuinely useful, useful enough to merit the added engine complexity as a result. 2. Not everyone agrees the problem even exists - in fact, most of us don't. "Number to array" is as simple as defining a `Symbol.iterator` method on `Number.prototype` and using `[...num]`. "Array to number" is just `+[...values]`, which evaluates to `Number(String([...values]))`. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Thu, Mar 7, 2019 at 7:29 PM guest271314 <[email protected]> wrote: >> >> @guest When making a language proposal, the first thing that should be on >> your mind isn't , but the problems you're trying to solve. And these >> problems can't just be simple toy problems like a code golf challenge - they >> have to be real-world problems in code you write for sites, apps, libraries, >> and so on. If it's so niche as to be useless outside a simple challenge, >> you're unlikely to get any sort of support for adding it. >> Also, when making a language proposal, it's your responsibility to persuade >> others of its usefulness. It's not others' responsibility to dispute it - >> they could just as easily ignore it and your proposal won't have a chance to >> be merged into the spec. You have to be the one to explain why it should be >> added. > > > What part of the proposal, in your view, did not read "it'd be nice if ..." > number to array <--> array to number specification and standardization? > > Not sure what you mean by "toy problems"? Do you mean only concepts that meet > *your* "toy" interests? Scale is irrelevant. The real world problem is > standardization of number to array, array to number conversion in JavaScript. > The use case for this user has been stated several times above: manipulation > of numbers as arrays with the standardization of what to expect - in > JavaScript code output - when array is converted back to number or decimal to > the maximum JavaScript can produce. That is obviously not a compelling reason > for users here. So what? Made the proposal anyway, without having any > expectation as to the outcome. > > > > On Fri, Mar 8, 2019 at 12:19 AM Isiah Meadows <[email protected]> wrote: >> >> @guest When making a language proposal, the first thing that should be >> on your mind isn't "it'd be nice if ...", but the problems you're >> trying to solve. And these problems can't just be simple toy problems >> like a code golf challenge - they have to be real-world problems in >> code you write for sites, apps, libraries, and so on. If it's so niche >> as to be useless outside a simple challenge, you're unlikely to get >> any sort of support for adding it. >> >> Also, when making a language proposal, it's your responsibility to >> persuade others of its usefulness. It's not others' responsibility to >> dispute it - they could just as easily ignore it and your proposal >> won't have a chance to be merged into the spec. You have to be the one >> to explain why it should be added. >> >> ----- >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> >> On Thu, Mar 7, 2019 at 7:09 PM guest271314 <[email protected]> wrote: >> > >> > That still leaves determining how many digits there are after the decimal >> > point and where the number added sums to greater than 10 carrying over the >> > remainder to the adjacent digits, if needed, which is simpler using array >> > methods where the .length after the index where the single decimal is >> > located in the array will provide the 10's, 100's, etc. >> > >> > If alternative solutions provide the expected results, without >> > standardization, simply disregard this proposal. The proposal is intended >> > to standardize the conversion from number to array and array to number. >> > >> > Consider the examples at the proposal, where several generator functions >> > can be used in parallel to adjust both 128.625 and 1.074 through and >> > beyond 1.144, where for example, input is "abcdefghi", we ignore the >> > values and permute only the indexes as a whole number and match the >> > multiples of 9 which meet the necessary criteria. >> > >> > In any event, do with the proposal as you will. >> > >> > On Thu, Mar 7, 2019 at 11:55 PM Gus Caplan <[email protected]> wrote: >> >> >> >> this seems like a solution in search of a problem. >> >> >> >> if you want to add a number in a specific place, you can just multiply it >> >> by that place. e.g. increasing the tenths place by 2 is n + (2 / 10), and >> >> increasing the tens place is n + (2 * 10). >> >> >> >> On Thu, Mar 7, 2019 at 5:42 PM guest271314 <[email protected]> wrote: >> >>> >> >>> FWIW the original requirement included a self-imposed restriction of >> >>> converting the input to a String at any point during the procedure, in >> >>> part to illustrate the ("broken") JavaScript Number/Math implementations. >> >>> >> >>> If you have a "simpler" implementation to the requirement, then post >> >>> your answer at SO. Am banned for 5 years - a few days, though will still >> >>> be able to view your answer. Or, post a gist. >> >>> >> >>> Yes, to settle the matter of a lot of users having a need for such an >> >>> implementation, can only speak for self. Have tried to solve the linked >> >>> OEIS A217626 oeis.org/A217626 for several years now - directly. That is, >> >>> specifically, using only a multiple of the number 9 to get *any* nth >> >>> permutation. That is how arrived at making this proposal here. >> >>> >> >>> On Thu, Mar 7, 2019 at 11:31 PM J Decker <[email protected]> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Thu, Mar 7, 2019 at 2:55 PM guest271314 <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>> Cannot get into "a large number of users" heads. Again, am not >> >>>>> interested in overcoming conjecture. If the proposal does not meet you >> >>>>> folks' criteria, so be it. >> >>>>> >> >>>>> On Thu, Mar 7, 2019 at 10:46 PM Steve Fink <[email protected]> wrote: >> >>>>>> >> >>>>>> Any addition to the JavaScript language needs to (1) be motivated by >> >>>>>> a use case encountered by a large number of users, (2) cannot be >> >>>>>> implemented in a straightforward and reliable way by a library, (4) >> >>>>>> is implementable by a JS implementation without undue trouble, and >> >>>>>> (4) does not conflict with other parts of the language. >> >>>>>> >> >>>>>> For your proposal: >> >>>>>> >> >>>>>> (1) - absolute fail >> >>>>>> (2) - arguable >> >>>>>> (3) - uncertain, depends on exact semantics >> >>>>>> (4) - pass >> >>>>>> >> >>>>>> Unless you can somehow prove that a large numbers of users give a >> >>>>>> rat's hindquarters about things that this would enable, this is a >> >>>>>> nonstarter. >> >>>>>> >> >>>>>> It would be useful to have a FAQ somewhere with a version of the >> >>>>>> above 4 rules that is better worked out and justified, so we could >> >>>>>> point to that. (From whatever public-facing forum is selected for the >> >>>>>> future; this one is dead.) >> >>>>>> >> >>>>>> On 3/7/19 2:22 PM, guest271314 wrote: >> >>>>>> >> >>>>>> Have you read the proposal, and the first response to your inquiry? >> >>>>>> 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). >> >>>>>> >> >>>>>> Will re-post a use case, again >> >>>>>> ~~(128.625*9*1.074)//1243 >> >>>>>> ~~(128.625*9*1.144)//1324 where if the requirement is to increment >> >>>>>> the decimal portion of 1.074 or 1.144 if the decimal is first >> >>>>>> converted to an array, we can use array methods to tests the matches >> >>>>>> we are looking for. For example, [1.0, 7, 4] >> >>>>>> representation of 1.074 allows each of the portions of the number to >> >>>>>> be adjusted independently. Since we have previously defined a >> >>>>>> .toNumber() Array method we know we can get the value of the array as >> >>>>>> a JavaScript number. >> >>>>>> >> >>>>>> On Thu, Mar 7, 2019 at 10:12 PM Jeremy Martin <[email protected]> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> By "real world" we mean somewhere outside of a code challenge or >> >>>>>>> similarly low utility program context. >> >>>>>>> >> >>>>>>> You mentioned statistics, for example. Can you reference a specific >> >>>>>>> example from that domain where these methods would offer an >> >>>>>>> advantage? >> >>>>>>> >> >>>>>>> On Thu, Mar 7, 2019, 5:05 PM guest271314 <[email protected]> >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Not sure what you mean by "real world" use case. Described at least >> >>>>>>>> one use case at the proposal. Statistics; graphs; number and >> >>>>>>>> integer manipulation using indexes of arrays with ability to >> >>>>>>>> convert manipulated array back to number. >> >>>>>>>> >> >>>>>>>> On Thu, Mar 7, 2019 at 9:56 PM Naveen Chawla >> >>>>>>>> <[email protected]> wrote: >> >>>>>>>>> >> >>>>>>>>> What is the real world use case, presuming it's not just an >> >>>>>>>>> academic exercise >> >>>>>>>>> >> >>>>>>>>> On Thu, 7 Mar 2019, 9:08 pm guest271314, <[email protected]> >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> Ability to adjust nth digit of an integer or decimal by adjusting >> >>>>>>>>>> decimal or integer at nth index of array, to try to solve OEIS >> >>>>>>>>>> A217626 oeis.org/A217626 directly, for example >> >>>>>>>>>> ~~(128.625*9*1.074)//1243 >> >>>>>>>>>> ~~(128.625*9*1.144)//1324 >> >>>>>>>>>> where the decimal portion can be manipulated by referencing the >> >>>>>>>>>> index of an array, then converting the array back to a number. >> >>>>>>>>>> >> >>>>>>>>>> On Thu, Mar 7, 2019 at 8:55 PM Jeremy Martin <[email protected]> >> >>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Can you explain the motivation for this proposal? >> >>>>>>>>>>> >> >>>>>>>>>>> At first blush, this seems like an incredibly arbitrary pair of >> >>>>>>>>>>> value conversion utilities. Are there real world applications >> >>>>>>>>>>> for this? >> >>>>>>>>>>> >> >>>>>>>>>>> On Thu, Mar 7, 2019 at 3:43 PM guest271314 >> >>>>>>>>>>> <[email protected]> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> ---------- Forwarded message --------- >> >>>>>>>>>>>> From: guest271314 <[email protected]> >> >>>>>>>>>>>> Date: Thu, Mar 7, 2019 at 8:35 PM >> >>>>>>>>>>>> Subject: Proposal: 1) Number (integer or decimal) to Array 2) >> >>>>>>>>>>>> Array to Number (integer or decimal) >> >>>>>>>>>>>> To: <[email protected]> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Original concept: Integer or decimal to array and array to >> >>>>>>>>>>>> decimal or integer >> >>>>>>>>>>>> https://codegolf.meta.stackexchange.com/a/17223 >> >>>>>>>>>>>> >> >>>>>>>>>>>> Proof of concept (with bugs) >> >>>>>>>>>>>> >> >>>>>>>>>>>> function numberToArray(n) { >> >>>>>>>>>>>> >> >>>>>>>>>>>> if (Math.abs(n) == 0 || Math.abs(n) == -0) { >> >>>>>>>>>>>> return [n] >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> const r = []; >> >>>>>>>>>>>> >> >>>>>>>>>>>> let [ >> >>>>>>>>>>>> a, int = Number.isInteger(a), d = g = [], e = i = 0 >> >>>>>>>>>>>> ] = [ n || this.valueOf()]; >> >>>>>>>>>>>> >> >>>>>>>>>>>> if (!int) { >> >>>>>>>>>>>> let e = ~~a; >> >>>>>>>>>>>> d = a - e; >> >>>>>>>>>>>> do { >> >>>>>>>>>>>> if (d < 1) ++i; >> >>>>>>>>>>>> d *= 10; >> >>>>>>>>>>>> } while (!Number.isInteger(d)); >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> for (; ~~a; r.unshift(~~(a % 10)), a /= 10); >> >>>>>>>>>>>> >> >>>>>>>>>>>> if (!int) { >> >>>>>>>>>>>> for (; ~~d; g.unshift(~~(d % 10)), d /= 10); >> >>>>>>>>>>>> g[0] = g[0] * (1 * (10 ** -i)) >> >>>>>>>>>>>> r.push(...g); >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> return r; >> >>>>>>>>>>>> >> >>>>>>>>>>>> } >> >>>>>>>>>>>> >> >>>>>>>>>>>> function arrayToNumber(a) { >> >>>>>>>>>>>> if ((Math.abs<span >> >>>>>>>>>>>> class="gmail-m_2662878951066317968m_7497912379499730396gmail-m_-49591865513921258gmail-m_191674293613409874m_-1290191079188355796gmail-pun" >> >>>>>>>>>>>> >> >>>>>>>>>>>> style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;font-family:inherit; >> >>>>>> >> >>>>>> >> >>>> >> >>>> Really though that the above would be simpler to implement. The >> >>>> example code doesn't even function correctly but... >> >>>> >> >>>> like 'numberTOArray(n)' would just be something like >> >>>> [... n.toString()].slice(1).map( >> >>>> (c,i)=>-1*(c.codePointAt(0)>=0x30?(c.codePointAt(0)-0x30): ((d=i),0)) ) >> >>>> >> >>>> ; but then going to read the original message I see it's actually quite >> >>>> convoluted. >> >>>> >> >>>> (it has an error of getting a trailing ... 0000000000000001 which >> >>>> causes the reverse to fail *shrug* ) >> >>>> >> >>>> function numberTOArray(n) { >> >>>> var d = -1; // decimal location >> >>>> var r; >> >>>> if( n < 0 ) >> >>>> r = [... n.toString()].slice(1).map( >> >>>> (c,i)=>-1*(c.codePointAt(0)>=0x30?(c.codePointAt(0)-0x30): ((d=i),0)) ) >> >>>> else >> >>>> r = [... n.toString()].map( >> >>>> (c,i)=>c.codePointAt(0)>=0x30?(c.codePointAt(0)-0x30):((d=i),0) ) >> >>>> var de = 0; // end of decimal leading 0's >> >>>> for( de = d; de < r.length; de++ ) >> >>>> if( r[de] != 0 ) break; >> >>>> r[d] = r[de] * Math.pow(10, (d-de)); >> >>>> r.splice( d+1, (de-d) ); >> >>>> return r; >> >>>> } >> >>>> >> >>>> function arrayTONumber(n) { >> >>>> var str; >> >>>> var d = -1; >> >>>> if( n[0]< 0 ) { >> >>>> str = n.map( (n,i)=>(n==0|| (n>=1 || n<=-1))?String.fromCodePoint( 0x30 >> >>>> + -n ):((d=i),'.') ).reduce( (acc,val)=>acc+val,'' ); >> >>>> if( d>=0 ) { >> >>>> str = str.substring(0,d+1) + n[d].toString().substring(2) + >> >>>> str.substring(d+1); >> >>>> } >> >>>> return -Number(str); >> >>>> } else { >> >>>> str =n.map( (n,i)=>(n==0|| (n>=1 || n<=-1))?String.fromCodePoint( 0x30 >> >>>> + n ):((d=i),'.') ).reduce( (acc,val)=>acc+val,'' ); >> >>>> if( d>=0 ) { >> >>>> str = str.substring(0,d+1) + n[d].toString().substring(2) + >> >>>> str.substring(d+1); >> >>>> } >> >>>> return Number(str); >> >>>> } >> >>>> } >> >>>> >> >>>> But ya; don't see a very general purpose in such a thing... >> >>>> >> >>>> >> >>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> es-discuss mailing list >> >>>>>> [email protected] >> >>>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> es-discuss mailing list >> >>>>>> [email protected] >> >>>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>>> >> >>>>> _______________________________________________ >> >>>>> es-discuss mailing list >> >>>>> [email protected] >> >>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>> >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> > >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
