Re: [Strawman proposal] StrictMath variant of Math
Thanks for the suggestion. As Ray pointed out, the Math package in Java still has its accuracy requirements specified and so it is not analogous to the current status of Math package in ES6. Also, the StrictMath package and the strictfp class qualifier came about in Java back when the x87 was the predominant FPU. Because of the idiosyncrasies of the x87 one could not compute bit-identical floating point results without additional overhead. Nevertheless, the accuracy requirements and conformance was still achieved with satisfactory performance. Much of the history is still available on-line http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html http://math.nist.gov/javanumerics/reports/jgfnwg-02.html It is unclear how much of these strict modes is still relevant given that SSE2 is now the predominant FPU. The strict modes were always effectively a non-issue on other architectures. Much of the pressure to relax the accuracy of the special functions seems to be coming from their use in various benchmark suites and the tireless efforts of the compiler engineers to squeeze out additional performance gains. Requiring bounds on the accuracy of the special functions has the additional benefit of putting all the browsers on equal ground so nobody has to have their product suffer the indignity of a benchmark loss because they try to do the right thing in the name of numerical accuracy. Carl On Thu, Jul 31, 2014 at 5:16 PM, Isiah Meadows impinb...@gmail.com wrote: I was looking at the number of complaints about the Math object, especially regarding the lack of required precision (refer to the thread Re: ES6 accuracy of special functions for a lengthy discussion on this). Because of this, I propose that a new object, StrictMath, should be added. This would be analogous to java.lang.Math (performance) vs java.util.StrictMath (accuracy). People could still define their own implementations if needed, though. Basic specs would be similar to the Math object, but with the following caveats: 1. Fixed-size integer methods such as Math.imul() don't need a StrictMath variant. 2. The input precision must be no more than a Float64 in size (depends on how this is spec'd, may not be necessary). 3. The output should have an error no greater than 1 ulp (the space between two adjacent, distinct floating point values, identical to the Java spec of an ulp). I don't see #2 staying if this is spec'd well, but the rest remain. Java's java.lang.StrictMath actually requires the fdlibm semantics and algorithm to be used for that class's implementations. java.lang.Math is closer to this spec in its own specification. -- Isiah Meadows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Strawman proposal] StrictMath variant of Math
On 1 Aug 2014, at 09:25, Carl Shapiro carl.shap...@gmail.com wrote: Thanks for the suggestion. As Ray pointed out, the Math package in Java still has its accuracy requirements specified and so it is not analogous to the current status of Math package in ES6. Also, the StrictMath package and the strictfp class qualifier came about in Java back when the x87 was the predominant FPU. Because of the idiosyncrasies of the x87 one could not compute bit-identical floating point results without additional overhead. Nevertheless, the accuracy requirements and conformance was still achieved with satisfactory performance. Much of the history is still available on-line http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html http://math.nist.gov/javanumerics/reports/jgfnwg-02.html It is unclear how much of these strict modes is still relevant given that SSE2 is now the predominant FPU. The strict modes were always effectively a non-issue on other architectures. Much of the pressure to relax the accuracy of the special functions seems to be coming from their use in various benchmark suites and the tireless efforts of the compiler engineers to squeeze out additional performance gains. Requiring bounds on the accuracy of the special functions has the additional benefit of putting all the browsers on equal ground so nobody has to have their product suffer the indignity of a benchmark loss because they try to do the right thing in the name of numerical accuracy. +1 Introducing a new global `Math` variant wouldn’t solve the interoperability issues. IMHO, the accuracy of the existing `Math` methods and properties should be codified in the spec instead. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why using the size property in set
yes in fact it makes sens because Set.length is the property of Set, not
necessary the length of the collection.
Thanks for your answers :)
2014-07-31 17:12 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
This was intentional
Allen
On Jul 31, 2014, at 5:24 AM, Nathan Wall ww...@google.com wrote:
Also, whether this was intentional or not, I think it's nice for objects
with `length` properties to all have properties at indices from `0` to
`length` (so they work in the `Array.prototype` methods) making `'length'
in foo` a lazy-man's `isArrayLike`.
```js
var forEach = Function.prototype.call.bind(Array.prototype.forEach);
forEach('foo', function(u) {
console.log(u);
});
```
On Thu, Jul 31, 2014 at 7:21 AM, David Bruant bruan...@gmail.com wrote:
Le 31/07/2014 09:25, Maxime Warnier a écrit :
Hi everybody,
I was reading the doc for the new Set method and something suprised me :
Why Set uses the size method instead of the length property ?
IIRC and with my own words length refers more to something that can be
measured contiguously (like a distance or a number of allocated bytes,
etc.) while size doesn't have this contiguous aspect to it.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Maxime WARNIER
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Strawman proposal] StrictMath variant of Math
Mathias Bynens wrote: On 1 Aug 2014, at 09:25, Carl Shapirocarl.shap...@gmail.com wrote: Thanks for the suggestion. As Ray pointed out, the Math package in Java still has its accuracy requirements specified and so it is not analogous to the current status of Math package in ES6. Also, the StrictMath package and the strictfp class qualifier came about in Java back when the x87 was the predominant FPU. Because of the idiosyncrasies of the x87 one could not compute bit-identical floating point results without additional overhead. Nevertheless, the accuracy requirements and conformance was still achieved with satisfactory performance. Much of the history is still available on-line http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html http://math.nist.gov/javanumerics/reports/jgfnwg-02.html It is unclear how much of these strict modes is still relevant given that SSE2 is now the predominant FPU. The strict modes were always effectively a non-issue on other architectures. Much of the pressure to relax the accuracy of the special functions seems to be coming from their use in various benchmark suites and the tireless efforts of the compiler engineers to squeeze out additional performance gains. Requiring bounds on the accuracy of the special functions has the additional benefit of putting all the browsers on equal ground so nobody has to have their product suffer the indignity of a benchmark loss because they try to do the right thing in the name of numerical accuracy. +1 Introducing a new global `Math` variant wouldn’t solve the interoperability issues. IMHO, the accuracy of the existing `Math` methods and properties should be codified in the spec instead. Right, we are not going to add StrictMath. The notes from this week's TC39 meeting at Microsoft will be published soon, some time next week, but to cut to the chase: we agreed to specify harder and stop the benchmarketing race to the bottom, as Carl suggested. We will need f.p. gurus helping review the work, for sure. Thanks to all of you contributing here. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Uniform block scoping
The general problem is that body blocks are not exactly blocks, due to
legacy cruft -- and this legacy cannot be separated from 'let' ideals
because we want programmers to refactor from 'var' to 'let'.
So we must give greater weight (compared to the ideal case of a body
block just being a block) to refactoring hazards that result in silent
but deadly bugs rather than early errors.
In particular,
function f(a) {
... // TDZ
let a = ...;
...
}
and
function g() {
try {
...
} catch (e) {
... // TDZ
let e = ...;
...
}
}
should be early errors because there's no useful shadowing going on with
'let' -- the TDZ means the outer binding cannot be used in the commented
places -- but any prior version using 'var' would have worked and
possibly allowed (coverage-dependent) uses of the outer (in catch's
case, var hoists across the catch head in sloppy code; in the parameter
case there's only ever one 'a' binding) use in the TDZ.
So an early error does no actual harm in either case, and helps avoid
bugs slipping past incomplete test coverage.
HTH,
/be
Brendan Eich wrote:
Andreas Rossberg wrote:
I think this subtle discrepancy is both unfortunate and unnecessary
[1]. Moreover, with ES7 do expressions, I would like it to hold that
(...) = {...}≡(...) = do {...}
I channeled you as best I could, and Dmitry Lomov kindly channeled you
on this point, but more than a few TC39ers objected that the left
arrow function, with a body block instead of a body expression, has
different semantics already, ignoring whether let x; in the body block
could shadow a parameter x. First, 'return' is the only way to return
a result in the left example, whereas thanks to do-expression being an
expression, the completion value (reformed) of the right ... is the
return value, even without 'return'.
I wanted to pass this back ASAP. More is being recorded in the meeting
notes, but here you go. We'll keep channeling you as best we can!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Strawman proposal] StrictMath variant of Math
On Fri, Aug 1, 2014 at 11:40 AM, Brendan Eich bren...@mozilla.org wrote: Mathias Bynens wrote: On 1 Aug 2014, at 09:25, Carl Shapirocarl.shap...@gmail.com wrote: Thanks for the suggestion. As Ray pointed out, the Math package in Java still has its accuracy requirements specified and so it is not analogous to the current status of Math package in ES6. Also, the StrictMath package and the strictfp class qualifier came about in Java back when the x87 was the predominant FPU. Because of the idiosyncrasies of the x87 one could not compute bit-identical floating point results without additional overhead. Nevertheless, the accuracy requirements and conformance was still achieved with satisfactory performance. Much of the history is still available on-line http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html http://math.nist.gov/javanumerics/reports/jgfnwg-02.html It is unclear how much of these strict modes is still relevant given that SSE2 is now the predominant FPU. The strict modes were always effectively a non-issue on other architectures. Much of the pressure to relax the accuracy of the special functions seems to be coming from their use in various benchmark suites and the tireless efforts of the compiler engineers to squeeze out additional performance gains. Requiring bounds on the accuracy of the special functions has the additional benefit of putting all the browsers on equal ground so nobody has to have their product suffer the indignity of a benchmark loss because they try to do the right thing in the name of numerical accuracy. +1 Introducing a new global `Math` variant wouldn’t solve the interoperability issues. IMHO, the accuracy of the existing `Math` methods and properties should be codified in the spec instead. Right, we are not going to add StrictMath. The notes from this week's TC39 meeting at Microsoft will be published soon, some time next week, but to cut to the chase: we agreed to specify harder and stop the benchmarketing race to the bottom, as Carl suggested. We will need f.p. gurus helping review the work, for sure. Thanks to all of you contributing here. This is really great news! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
