Proposal: Add a global Infinitesimal property
Number.MIN_VALUE already exists.
Ok. How about Number.NEGATIVE_MIN_VALUE
Already available, just prepend a minus sign like so:
-Number.MIN_VALUE
Yours would be much longer to type and brings no additional value.
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?
@kdex
Please compare to the inclusion of Number.POSITIVE_INFINITY, and Number.NEGATIVE_INFINITY.
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.
If Number.EPSILON does not exist then yes we should add it. I have no problems adding synonyms.
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.
@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.
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?
A good place to start is [1].
[1] tc39/proposals
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.
Thank you, i am already partway through the March 2018 TC39 meeting notes from day III
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
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.
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
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.
@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.
Ah I think you're right, I had the value of MIN_VALUE wrong, sorry.
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.
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.