|
|
12
|
|
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. -- Abdul S.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
`Number.MIN_VALUE` already exists.
On Saturday, May 12, 2018 6:49:32 PM CEST Abdul Shabazz 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. _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
Already available, just prepend a minus sign like so:
```js
-Number.MIN_VALUE
```
Yours would be much longer to type and brings no additional value.
On Saturday, May 12, 2018 6:54:42 PM CEST Abdul Shabazz wrote:
> Ok. How about Number.NEGATIVE_MIN_VALUE _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
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. _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
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. _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
I wasn't aware of the committees view of synonyms and that they perceive them ad clutter. This unfortunate but i will moderate my future suggestions accordingly. btw where can i find their submission/proposal guidelines? -- Abdul S.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
A good place to start is [1].
[1] https://github.com/tc39/proposalsOn Saturday, May 12, 2018 7:11:36 PM CEST Abdul Shabazz wrote:
> I wasn't aware of the committees view of synonyms and that they perceive
> them ad clutter. This unfortunate but i will moderate my future suggestions
> accordingly. btw where can i find their submission/proposal guidelines? _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
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.
I strongly encourage thorough familiarization with all those documents, including the spec/language itself, if you want to increase the effectiveness of a proposal. _______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
> https://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 https://github.com/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 On Sat, May 12, 2018 at 10:45 PM Jordan Harband < [hidden email]> wrote: 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.
I strongly encourage thorough familiarization with all those documents, including the spec/language itself, if you want to increase the effectiveness of a proposal.
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
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 On Sat, May 12, 2018 at 11:27 PM Jordan Harband < [hidden email]> wrote: 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
|
|
@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`.
On Saturday, May 12, 2018 7:01:38 PM CEST Logan Smyth wrote:
> 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`?
>
> On Sat, May 12, 2018 at 9:57 AM, kdex < [hidden email]> wrote:
> > Already available, just prepend a minus sign like so:
> >
> > ```js
> > -Number.MIN_VALUE
> > ```
> >
> > Yours would be much longer to type and brings no additional value.
> >
> > On Saturday, May 12, 2018 6:54:42 PM CEST Abdul Shabazz wrote:
> > > Ok. How about Number.NEGATIVE_MIN_VALUE
> >
> > _______________________________________________
> > es-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
|
12
|
Locked
signature.asc (849 bytes)