@Brendan that's great! (I sent my message early by accident)

Isiah Meadows
On Aug 2, 2014 4:31 PM, "Isiah Meadows" <impinball at gmail.com> wrote:

> 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/c0fea33e/attachment.html>

@Brendan that's great! (I sent my message early by accident)