Proposal: Add a global Infinitesimal property

# Abdul Shabazz (15 days ago)

As polar opposite to Infinity, Number.POSITIVE_INFINITY, the Infinitesimal should be a smallest representable value greater than 0. Perhaps someone else could propose why this would be useful.

# kdex (15 days ago)

Number.MIN_VALUE already exists.

# Abdul Shabazz (15 days ago)

Ok. How about Number.NEGATIVE_MIN_VALUE

# kdex (15 days ago)

Already available, just prepend a minus sign like so:

-Number.MIN_VALUE

Yours would be much longer to type and brings no additional value.

# Logan Smyth (15 days ago)

It doesn't sound like Number.MIN_VALUE is what you want, is it? You're asking for something like Number.EPSILON, but relative to 0 instead of 1?

# Abdul Shabazz (15 days ago)

@kdex

Please compare to the inclusion of Number.POSITIVE_INFINITY, and Number.NEGATIVE_INFINITY.

# Abdul Shabazz (15 days ago)

If Number.EPSILON does not exist then yes we should add it. I have no problems adding synonyms.

# Jordan Harband (15 days ago)

If one is not sure why something would be useful, then one should not propose anything.

Do you have a use case for this, or would it address an inconsistency in the language? If so, great, please share! If not, then there's not really anything to discuss.

# Jordan Harband (15 days ago)

Number.EPSILON was added in ES2015.

The committee generally does have a problem adding synonyms; that does not add any significant value, while it does add complexity.

# Abdul Shabazz (15 days ago)

@Jordan Harband

Sorry i just dont agree; i don't create things which have meaning, i give meaning to things i create. This allows me to innovate faster.

# Abdul Shabazz (15 days ago)

I wasn't aware of the committees view of synonyms and that they perceive them as clutter. This is unfortunate but i will moderate my future suggestions accordingly. btw where can i find their submission/proposal guidelines?

# kdex (15 days ago)

A good place to start is [1].

[1] tc39/proposals

# Jordan Harband (15 days ago)

They're not written down anywhere, and they change based on the makeup of the committee.

However, in general, the wider committee strives to avoid complexity, and absolutely will demand a justification for adding anything to JavaScript, including for changing the process by which changes are made to JavaScript.

tc39/proposals is the list of current proposals, tc39.github.io/process-document describes the stage process, and tc39/ecma262/blob/master/CONTRIBUTING.md describes how one can contribute.

I strongly encourage thorough familiarization with all those documents, including the spec/language itself, if you want to increase the effectiveness of a proposal.

# Abdul Shabazz (15 days ago)

Thank you, i am already partway through the March 2018 TC39 meeting notes from day III

# Bob Myers (15 days ago)

tc39.github.io/process-document

This document says that there are no entrance criteria for Stage 0. In practice, however, when I attempted to add a proposal to the phase 0 list, via a PR to tc39/proposals/blob/master/stage-0-proposals.md, it was rejected based on the fact that a champion is in fact required even for stage 0, and all the proposals listed on the stage 0 page do indeed have champions listed.

I seem to recall pointing out this inconsistency a long time ago and someone responded that the docs were out of date and would be fixed pretty soon.

Bob

# Jordan Harband (15 days ago)

The document says both "The TC39 committee must approve acceptance for each stage." (which I read as, even if there's no entrance criteria) and "Such submissions must either come from members of TC39 or from non-members who have registered via Ecma International,", for one, but in practice, inclusion into the proposals repo requires involvement (championing or otherwise) from a TC39 member.

# Bob Myers (15 days ago)

Thanks for your quick reply.

in practice, inclusion into the proposals repo requires involvement (championing or otherwise) from a TC39 member

With all due respect, if that is the practice, then the document should reflect that practice. FWIW, I did register as specified by that page.

The TC39 committee must approve acceptance for each stage

I see. I missed that. I'm curious, though. Since many of the stage 0 proposals have no "Last Presented" date shown, in what form and by what process was the acceptance of said stage 0 proposals approved by the TC39 committee? If in fact such proposals were never actually accepted by means of any documented procedure, someone with strong bureaucratic tendencies might insist that they be removed and re-accepted via a correct approval procedure in order to maintain conformance with TC39's own stated processes.

-- Bob

# Mark Miller (15 days ago)

See the entire thread at < esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks>.

While this position is in no way official, several of the reactions on the thread are from other committee members, and so serves as an indication of attitudes common on the committee.

See especially the bulleted list at < esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22>

which prioritizes these concerns.

# kdex (14 days ago)

@Logan:

I think the number you're describing there is exactly Number.MIN_VALUE, isn't it?

The machine epsilon is the smallest value ε for which 1 + ε > 1.

If we were to consider the relative-to-zero case, we would instead look for an ε such that 0 + ε > 0 holds. Number.MIN_VALUE has this property, since

0 + Number.MIN_VALUE === Number.MIN_VALUE

and there are no positive values smaller than Number.MIN_VALUE.

# Logan Smyth (14 days ago)

Ah I think you're right, I had the value of MIN_VALUE wrong, sorry.

# Tab Atkins Jr. (13 days ago)

On Sat, May 12, 2018 at 9:49 AM, Abdul Shabazz <ahshabazz2017 at gmail.com> wrote:

As polar opposite to Infinity, Number.POSITIVE_INFINITY, the Infinitesimal should be a smallest representable value greater than 0. Perhaps someone else could propose why this would be useful.

Please stop suggesting things that you don't even think are useful. Feature proposals, on their own, are not useful for a standards body; there are an infinity of features we could add. What we need is problems you're having, and then possibly a suggested new feature to help solve that problem. Without the problem we have no reason to think that adding the feature would help anyone, so there's no reason to add it.