Naming

[bakkot]

Given that this proposal now requires exact summation, is Math.sum still the right name? In some sense yes, but it may be surprising to users that Math.sum(a, b, c) gives a different answer (and is potentially slower) than a + b + c.

Maybe Math.sumExact?

[ljharb]

I would be surprised if users find that surprising, since that’s kind of the point of the method. sumExact imo begs the question of why + isn’t exact.

[bakkot]

sumExact imo begs the question of why + isn’t exact.

Well, yes, that's a good question for users to ask, if they're summing a big list of numbers. I think drawing attention to that distinction is possibly valuable.

[ljharb]

If it needs drawing attention to, then that either means nobody’s noticing the difference or that nobody’s confused, no?

[bakkot]

I think it maybe needs drawing attention to because people might be confused.

[hax]

I guess people may also ask why only sumExact, no productExact?

[bakkot]

Further naming bikeshed: given that this takes an iterable instead of being variadic, should this be sumExact or sumExactFrom?

[ljharb]

"From" isn't a universal convention when something takes an iterable, so I don't think that's strictly necessary.

[michaelficarra]

@ljharb It may not be universal, but it still makes a strong implication, which can be helpful. I like sumExactFrom despite the verbosity.

[bakkot]

Closing: in plenary we decided on sumPrecise.

[theScottyJam]

I know this has already been decided, but I'm going to throw in my 2-cents dislike towards the name "sumExact()".

For the vast majority of places where this function will be used, the exactness of the summing algorithm won't be an important factor. The fact that it follows a more precise algorithm feels more like a detail that belongs in the documentation, as something extra you can learn about if you want to dig in detail - it's not something that needs to be called out every time the function gets used.

If we followed this kind of naming everywhere, we'd end up with function names like these:

// The sorting algorithm for .sort() is implementation specific
array.implementationSpecificSort();

// .flatMap() is faster than doing just .map().flat(),
array.fastFlatMap();

// Object.keys() doesn't pick inherited keys or symbol keys.
Object.ownStringKeys()

// etc

In the end, it's not a huge deal to me, it just feels unfortunate to be calling out what is typically an insignificant detail every time I use the function.

[tophf]

Maybe Iterator.sumPrecise to explicitly indicate the type of the input?

[bakkot]

The type of the input is an iterable, not an iterator.

[ljharb]

Also, the object that holds the method usually implies the output, not the input. Array.from, for example.

[tophf]

Number.sum then :-)

[bakkot]

The namespace that holds the functions which do computations on Numbers is Math. It's definitely not going to go anywhere other than on Math.