Additional Math functions

[Eli Perelman]

We aren't really arguing whether this can be in a separate library; in
fact, it is probably implemented many times over in separate libraries. My
argument is more that there is a deficiency if this must be reimplemented
many times across those libraries. Another deficiency lies in the fact that
Math contains many complex functions but does not contain simple ones like
summation and mean. I believe if ES can be the building block for a good
math library of userland functions, there are probably several core
functions that should be specified at the language level, because
efficiency, etc.

Eli Perelman

On Mon, Oct 5, 2015 at 6:06 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> Am I the only one here wondering if at least most of this belongs in a
> separate library, rather than JS core?
>
> 1. Most everyday programmers would be okay with this. 100% accuracy
> isn't a requirement, but speed often is.
>
> ```js
> Math.sum = (...xs) => xs.reduce((a, b) => a + b, 0);
> Math.mean = (...xs) => Math.sum(...xs) / xs.length;
> // etc...
> ```
>
> 2. Most scientific programmers need accuracy to the finest point.
> Speed isn't usually of much priority beyond just the big-O complexity,
> but accuracy is.
>
> I see two extremely different use cases here. Even a C implementation
> may not be able to satisfy both worlds. In tight loops, I will still
> see this, even in C++:
>
> ```cpp
> template<typename T>
> static inline T sum(T* entries, int len) {
>   T sum = 0;
>   while (len) sum += entries[--len];
>   return sum;
> }
> ```
>
> We all know that it's subject to inaccuracy, but it's still useful in
> certain circumstances.
>
> Does this belong in a library, not the spec itself?
>
> On Sun, Oct 4, 2015 at 3:40 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
> >
> >
> > On Thu, Oct 1, 2015 at 6:52 PM Eli Perelman <eli at eliperelman.com> wrote:
> >>
> >> Reviving this thread, doing any type of simple statistics is more
> verbose
> >> than it probably needs to be as calculating sums, averages, etc. makes
> most
> >> resort to Array reduction. I understand the need for methods such as
> >> `Math.hypot(...values)`, but for ECMAScript to evolve to be useful in
> >> statistics programming without needing to resort to R would definitely
> also
> >> be a nice-to-have. I'm sure there are many statistical functions you
> *could*
> >> add, but at a bare minimum, it would be useful:
> >>
> >> Math.sum(...values) or Math.summation(...values)
> >> Math.mean(...values) // Spelling out mean here is succinct while still
> >> intentional, instead of .avg
> >> Math.variance(...values)
> >> Math.stddev(...values)
> >>
> >> Obviously some of these can be computed from the results of others, but
> I
> >> think the convenience and intent of the methods, not to mention their
> wide
> >> usefulness outweigh the concern of Math bloat. Thoughts?
> >>
> >> P.S. Definitely not against even more core stats methods, but have to
> >> start somewhere. :)
> >
> >
> > Can you write up some preliminary proposal specifications? Here are some
> > useful resource/references to get started with proposal/spec authoring:
> >
> > - https://github.com/tc39/ecmascript-asyncawait
> > - https://github.com/tc39/ecma402
> > - https://github.com/tc39/ecmascript_simd
> > - https://github.com/tc39/Array.prototype.includes
> >
> > Thanks!
> >
> > Rick
> >
> >
> >>
> >>
> >> Eli Perelman
> >> Mozilla
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Isiah Meadows
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151005/793c6e86/attachment.html>