Additional Math functions

Michael McGlothlin mike.mcglothlin at gmail.com
Fri Oct 9 15:26:07 UTC 2015


Why include numbers at all? Some people only manipulate strings so why not
leave numbers to a third-party library that might be better? Or maybe we
should use a string type that randomly drops lowercase characters because
uppercase is good enough for many people. People that want to keep those
characters can just use a third-party library.

On Tue, Oct 6, 2015 at 9:12 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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
>>
>
> _______________________________________________
> 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/20151009/6c5a6d43/attachment-0001.html>


More information about the es-discuss mailing list