That would also make sense. I do feel that the Math spec should have at
least a base requirement. Java requires fdlibm as a baseline, but the
correctly rounded requirement would be even better. Definitely a loophole
that should've already been closed by now.

Isiah Meadows
On Aug 1, 2014 4:14 PM, "Raymond Toy" <toy.raymond at gmail.com> wrote:

>
>
>
> On Fri, Aug 1, 2014 at 11:40 AM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> Mathias Bynens wrote:
>>
>>> On 1 Aug 2014, at 09:25, Carl Shapiro<carl.shapiro at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140802/e6d4b39f/attachment.html>

That would also make sense. I do feel that the Math spec should have at
least a base requirement. Java requires fdlibm as a baseline, but the
correctly rounded requirement would be even better. Definitely a loophole
that should've already been closed by now.