Additional Math functions
Isiah Meadows
isiahmeadows at gmail.com
Wed Oct 7 02:12:05 UTC 2015
Jason, I agree. Although I didn't exactly make it explicit enough, that was
my basic reasoning.
On Tue, Oct 6, 2015, 14:03 Jason Orendorff <jason.orendorff at gmail.com>
wrote:
> On Fri, Oct 2, 2015 at 6:37 PM, Alexander Jones <alex at weej.com> wrote:
> > What do other languages do?
>
> Well, Python's standard library has both a `sum()` builtin and a
> statistics module. They handle floating-point weirdness differently:
>
> >>> sum([1.0, 1e18, -1e18])
> 0.0
> >>> import statistics
> >>> statistics.mean([1.0, 1e18, -1e18])
> 0.3333333333333333
>
> See <https://www.python.org/dev/peps/pep-0450/> for statistics module
> rationale. I didn't find a PEP for sum().
>
> ...But for JS, the question is: why should we think TC39 and JS
> engines will be as good at satisfying this need as third-party
> libraries?
>
> I hope that users who require numerical accuracy can just crack open a
> book. They should have, in JS, all the floating-point-munging tools
> they need to implement a book algorithm. If they don't, let's focus on
> providing those!
>
> *Maybe* JS engine implementors can provide as-good accuracy with
> better speed. But not necessarily. A standard Math.sum() may even be
> slower, because TC39 is likely to specify nice, consistent, but
> inconvenient behavior, such as supporting the iterator protocol or
> specially handling array holes or infinities or NaN or -0. Library
> authors don't have to care about this stuff. TC39 absolutely has to
> care---about the risks of underspecification, at least---even at the
> expense of speed.
>
> -j
> _______________________________________________
> 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/20151007/b29814b1/attachment.html>
More information about the es-discuss
mailing list