>
> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply standard western academic
conjecture. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; etc., et al., without rancor.
That is just who or what people are, especially within the realm of western
academia. Do not care one way or the other, as am not a disciple of that
regime ("Do what thou wilt shall be the whole of the Law"). Brought this to
tc39 attention once examples of working code were completed.



On Fri, Mar 8, 2019 at 2:35 AM Augusto Moura <augusto.borgesm at gmail.com>
wrote:

> There is space for improvement in low level programming in Javascript,
> sure isn't the main focus of the language, but I don't think
> unobtrusive proposals should be a problem. There's a lot of C/C++
> number apis that would be really useful in some use cases (I'm
> thinking now in matrix operations, graphics and games).
>
> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it
> that got popular in a niche? Having any examples of implementations
> (aside for your own of course) would help your proposal immensely. I'm
> not being toxic here this is a really specific use-case that I know
> almost nothing.
>
> About users not being concerned with your problem, we have to be
> really cautious when supporting proposals, we can't just add every
> function and syntax that solves someone problems, the language would
> became bloated and complex rapidly. There's a fantastic thread [1]
> that explains the point a lot better than me and you should definitely
> read it.
>
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.
>
> Em qui, 7 de mar de 2019 às 21:56, guest271314 <guest271314 at gmail.com>
> escreveu:
> >
> > Not sure if your failure thus far to gather what the proposal is
> actually suggesting is based on your limited experimentation in using
> numbers in JavaScript, or some other reason. That is ok. Your second point
> illustrates the problem faced. Where your pseudo code uses String methods.
> That should not be necessary. Further, where in the resulting array are you
> separating the decimal portion of the number? How do you convert a decimal
> or irrational number to JavaScript numbers in an array, accounting for the
> decimal? None of those inquiries have standardized answers. You folks write
> standards. Only asked the question on coding sites to not solely rely on
> own approach to solving the inquiry, which ordinarily achieve before asking
> the question.
> >
> > It is not a "homework" project. Again, have no issues solving own coding
> problems. It is not a coding challenge. It is a proposal to standardize
> conversion of number to array <--> array to number. If you want to include
> "ranges" in the proposal, have composed code for that output as well. The
> issue is consistency (is an individual were to have such expectations) of
> output in conversion in each of array to number and number to array. Am not
> concerned with what you refer to as "apps", that is your *business*. The
> proposal is for standardization of handling decimals to and from an array.
> >
> > That is obviously not a concern for you, or users here.
> >
> >
> >
> > On Fri, Mar 8, 2019 at 12:40 AM Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >>
> >> > 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
> >> contact at isiahmeadows.com
> >> www.isiahmeadows.com
> >>
> >> On Thu, Mar 7, 2019 at 7:29 PM guest271314 <guest271314 at gmail.com>
> 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 <isiahmeadows at gmail.com>
> 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
> >> >> contact at isiahmeadows.com
> >> >> www.isiahmeadows.com
> >> >>
> >> >> On Thu, Mar 7, 2019 at 7:09 PM guest271314 <guest271314 at gmail.com>
> 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 <me at gus.host> 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 <guest271314 at gmail.com>
> 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 <d3ck0r at gmail.com>
> wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On Thu, Mar 7, 2019 at 2:55 PM guest271314 <
> guest271314 at gmail.com> 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 <sphink at gmail.com>
> 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 <
> jmar777 at gmail.com> 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 <
> guest271314 at gmail.com> 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 <
> naveen.chwl at gmail.com> 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, <
> guest271314 at gmail.com> 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 <
> jmar777 at gmail.com> 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 <
> guest271314 at gmail.com> wrote:
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> ---------- Forwarded message ---------
> >> >> >>>>>>>>>>>> From: guest271314 <guest271314 at gmail.com>
> >> >> >>>>>>>>>>>> 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: <es-discuss at mozilla.org>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>>
> >> >> >>>>>>>>>>>> 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
> >> >> >>>>>> 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
> >> >> >>>>>
> >> >> >>>>> _______________________________________________
> >> >> >>>>> 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
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190308/4655cfdc/attachment-0001.html>

> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

> About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply conjecture; western academic SOP. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; et al. etc., without rancor.
Do not care one way or the other, as am not a disciple of or enamored with that or any other
regime. Brought this to
tc39 attention once examples of working code were completed. Do or do not do what thou wilst.

> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

> About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply conjecture; western academic SOP. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; etc., et al., without rancor.
Do not care one way or the other, as am not a disciple of or enamored with that or any other
regime. Brought this to
tc39 attention once examples of working code were completed. Do or do not do what thou wilst.

> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

> About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply western academic
conjecture; SOP. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; etc., et al., without rancor.
Do not care one way or the other, as am not a disciple of or enamored with that or any other
regime. Brought this to
tc39 attention once examples of working code were completed. Do or do not do what thou wilst.

> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

> About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply standard western academic
conjecture. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; etc., et al., without rancor. That is how western academia operates.
Do not care one way or the other, as am not a disciple of or enamored with that or any other
regime. Brought this to
tc39 attention once examples of working code were completed. Do or do not do what thou wilst.

> There's any prior art/work in your idea? Any C or other languages
> functions, any spec'd norm (IEEE, ISO)? Or any library implementing it that
> got popular in a niche? Having any examples of implementations (aside for
> your own of course) would help your proposal immensely. I'm not being toxic
> here this is a really specific use-case that I know almost nothing.


There is prior art relevant to determining where the decimal portion of a
number is, which is linked at the SO question. AFAIK there is no prior art
relevant to the full conversion from number to array and array to number,
including decimal numbers.

The proposal does not ask for code to solve the problem. The proposal asks
for this body to consider standardizing the procedure in a specification.

For example, given input the number *e*  2.718281828459045, could be
represented in an array in several different manners

    [2, .718281828459045]

    [2.7, 18281828459045]

    [2, 0.7, 1, 8, 2, 8, 1, 8, 2, 8, 4, 5, 9]

And there is also the case of negative integer and negative decimal
representations. These different representations of numbers in an array
could be given appropriate names for disambiguation, by a standardization
body. From perspective here the last representation provides the most
flexibility, though the others could be useful for different applications.

> About users not being concerned with your problem, we have to be really
> cautious when supporting proposals, we can't just add every function and
> syntax that solves someone problems, the language would became bloated and
> complex rapidly. There's a fantastic thread [1] that explains the point a
> lot better than me and you should definitely read it.
> Don't be angered if we don't give a lot of reception for your first
> proposal, you can always improve your idea or get a new one.


Whether this body decides to move forward addressing the matter or not is
*your* decision.

Am not "angered". The responses are simply standard western academic
conjecture. Address such conjecture routinely in all fields of endeavor;
from history to biology to physics to law; etc., et al., without rancor.
That is just who or what people are, especially within the realm of western
academia. Do not care one way or the other, as am not a disciple of that
regime ("Do what thou wilt shall be the whole of the Law"). Brought this to
tc39 attention once examples of working code were completed.