Additional Math functions

[Marius Gundersen]

Wouldn't it make sense to wait for the bind syntax [1] before introducing
new methods that work on arrays? That way it could be added to a standard
or non-standard module without altering either the Math object or the
Array/Iterator prototype. Something like this:

```
import {sum, mean} from "iterator-math";

[1,2,3,4]::sum(); //10
[1,2,3,4]::mean(); //2.5
[{a:1}, {a:2}, {a:3}, {a:4}].map(x => x.a)::sum(); //10
```

[1] https://github.com/zenparsing/es-function-bind

Marius Gundersen

On Mon, Oct 5, 2015 at 3:54 PM, Eli Perelman <eli at eliperelman.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20151005/80e483c6/attachment-0001.html>