Built-in module for array-oriented math functions?

[claudiameadows]

I rarely use Math.max as nearly all of my use cases are for lists and spreading potentially hundreds to tens of thousands of arguments (depending on the data set) is obviously not a good idea. (It's also slower) Additionally, there are a few statistical functions that come up a little more than the rest.

Here's a list of things I'd like to see:

• sum(list, by?): number
• product(list, by?): number
• min(list, by?): value
• max(list, by?): value
• average(list, by?): number
• quantile(q, list, by?): number
• median(list, by?): number
• count(list): Map<value, number>

Most of these have precedent in standard utility libraries, specifically with lists:

• Lodash has the following:
  • sum → _.sum
  • min → _.min
  • max → _.max
  • average → _.mean
  • count → _.countBy
• Underscore has the following:
  • min → _.min
  • max → _.max
  • count → _.countBy
• Ramda has the following:
  • sum → R.sum
  • product → R.product
  • min → R.min
  • max → R.max
  • average → R.mean
  • median → R.median
  • count → R.countBy

My proposed count is similar to GitHub - tc39/proposal-array-grouping: A proposal to make grouping of array items easier, but instead of returning an object of lists, it's a map of pure lengths (which is much cheaper to calculate). mode isn't provided as it's literally as simple as max(count(list), ([k, v]) => v)[0].

The only one of those that isn't listed above, quantile, is probably the most common statistic I've seen in practice after the above, and outside numerical computing contexts, is about the only one I've ever needed of the major statistical functions as it comes in handy with benchmarks and metrics as a more pragmatically useful alternative to max (q=1) and min (q=0). While technically median (q=0.5) could be implemented in terms of quantile as proposed here (and really, specified in terms of it), I'm providing it as a separate function.

Yes, there's been some recent noise about this already, but I would like to hold back from actually specifying where they'd go, because it's a bit early for that.

[ljharb]

In case they weren’t mentioned upthread (this showed up in my email as a stand-alone email instead of part of a thread of replies, for some reason) there’s a bunch of open proposals for Math methods£

• https://github.com/rwaldron/proposal-math-extensions
• https://github.com/tc39/proposal-Math.signbit
• https://docs.google.com/presentation/d/1Ta_IbravBUOvu7LUhlN49SvLU-8G8bIQnsS08P3Z4vY/edit?usp=sharing
• https://github.com/tc39/proposal-seeded-random
• https://github.com/phoddie/integer-and-modulus-math-proposal
• https://github.com/tc39/proposal-bigint-math

The subject/title mentions “built-in module”, and altho i think those advancing is unlikely, it’s probably best to not derail the thread discussing where it might live, since that’s not really relevant until stage 2.

[Jonas_Wilms]

I definitely agree that these utilities would be really useful (especially average and sum, hate to use reduce for that). One comment on:

@claudiameadows

I rarely use Math.max as nearly all of my use cases are for lists and spreading potentially hundreds to tens of thousands of arguments (depending on the data set) is obviously not a good idea.

That should be a trivial optimization for the engine, as Math.max is probably an intrinsic anyway. I'd rather say this is a bug / missed opportunity in the engine and not something the language specification should care about. I do however see that the additional arguments (namely the "by") will be very convenient, so I do see good reasons not to use a rest parameter on the new functions.

Instead of "list" I'd rather use the specified "iterable" ...