Feature #14399: Add Enumerable#product

• Status: Open
• Assignee: -
• Target version: -

[jzakiya (Jabari Zakiya)]

For similar reasons for creating Enumerable#sum a companion method
Enumerable#product is also very useful. Taking the product of
numbers in arrays is a common operation in many numerical algorithms,
especially in number theory and cryptography, and its optimization in
Ruby will make it more conducive to math heavy algorithms and tasks.

This

> [2,3,5,7].reduce(:*) => 210

can be optimized to this

> [2,3,5,7].product => 210

It should also allow an initial value

> [2,3,5,7].product(2) => 420

> [2,3,5,7].product(0.5) => 105

Crystal already has this method.

[shan (Shannon Skipper)]

Array#product would stomp on Enumerable#product, and it confusingly does a different thing:

[2,3,5,7].product => [[2], [3], [5], [7]]

Maybe Enumerable#multiply would compliment Enumerable#sum?

[jzakiya (Jabari Zakiya)]

I looked here https://ruby-doc.org/core-2.5.0/Enumerable.html and didn't see
that method, so I didn't know it existed. But multiply would also work.

Where in the docs is product?

The Ruby product then causes a conflict with the Crystal definition/use.

[jzakiya (Jabari Zakiya)]

Duh, ok, its an Array method.

[jzakiya (Jabari Zakiya)]

Actually, after looking at the docs for Array#product a
better name would be Array#combinations, which is a little
longer, but I think is more accurately descriptive and intuitive.
Oh well, cats out the bag now.

[shevegen (Robert A. Heiler)]

which is a little longer, but I think is more accurately
descriptive and intuitive.

We are back to the ancient problem - giving things good names. :-)

The only name from the above that I like is .sum - the others
do not tell me much at all. ;-)

I am not sure what .combinations would do - then again I also
never fully understood the name .reduce() either. People
often associate different actions with the same (but also
different) names.

[jzakiya (Jabari Zakiya)]

That's interesting because I never intuitively understood the use
of inject, especially for numerical purposes, and always now use
reduce, which was (I believe) created by Haskell (the person and
programming language), and has long been a concept in functional
programming. To me it says that an array of numbers (items) will be
reduced|collapsed into a single value based on the given operation.

Also, after reading your comment and thinking about it, there is a way
to reclaim the product method name and recast it for this new (better) use.

A better name for the current Array#product is Array#combine, which has
the same number of characters, so it can replace the word inplace in code
without the need to possibly reformat it.

[1,2,3].product [5,6,7] which seems like a vector|matrix operation

can be renamed as

[1,2,3].combine [5,6,7] or even [1,2,3].combine_with [5,6,7}

I think this is much clearer indication of its intent and purpose.

Here's a proposed path to reclaim and recast product as proposed.

Ruby 2.6
Introduce Array#combine(_with) as an alias to the current Array#product.
Replace its use in the Ruby core and stdlib code.
Make announcement to deprecate use of Array#product to give people time to change.

Introduce Enumerable#multiply to act as proposed Enumerable#product.

Ruby 2.7
Eliminate use of Array#product
Create Enumerable#product as alias of Enumerable#multiply

Since everyone knows Ruby 3 is going to be a breaking some old code change, if
people are weaned off old code use then this change really won't create problems.
On one hand you are creating a new capability in Enumerable#[product|multiply]
while keeping, but renaming, a current capability. Plus, I can't think that alot of
code|people currently use Array#product, so I doubt it affects a lot of code|people.
(Is this ever used in Rails, etc?)

Python went through this going from 2 to 3, famously with the print method change.

Basically what I'm illustrating, if there is a will there is a way to make this change,
without a lot of disruption and pain.

[nate00 (Nate Sullivan)]

I believe Enumerable#product is named after the Cartesian product (also called just "product" in set theory). For example, see the discussion in issue 7444. Renaming it to combinations or combine might cause people to think it's related to mathematical combinations, but as far as I can tell, it isn't related.

[jzakiya (Jabari Zakiya)]

According to the thread you provided the initial suggested name was Array#product_set
which was shortened to the current Array#product. Its proposed intent was to provide
combination groups of set-like items, and not as an arithmetic operation.

As was stated previously, naming things is Hard!, especially when you can't anticipate all
the unintended consequences.

I think Crystal has gotten it correct for this, having both Enumerable#product and
Enumerable#sum methods. I suspect the overwhelming majority of programmers|users
coming to Ruby would expects the following behavior too.

[2,3,5,7].sum => 17        # the result of adding all the array elements

[2,3,5,7].product => 210   # the result of multiplying all the array elements

[joanbm (Joan Blackmoore)]

EDIT: The original request was updated and my comment is related to the meaning of previous one. I don't agree with adding method of identical name but distinct semantic, ie. existing Array#product as a Cartesian product of elements and Enumerable#product as a product of their multiplication. It would only bring inconsistency and confusion, esp. conflicting while Array includes Enumerable.

I'd also vote YES for this feature request, move #product into Enumerable.

It is especially missing when working with (lazy) infinite sequences and problems leading to cartesian product of elements. Now it has to be implemented by nesting blocks of Enumerable#flat_map, which is cumbersome and inelegant when, ironically, there is method already available but for Array (sub)class(es) only.

p.s. Please stay on topic, discussion about chosen method name is pointless because it is already there. Backward compatibility should be kept as possible and its name is also justified although opinions may differ.

[jwmittag (Jörg W Mittag)]

jzakiya (Jabari Zakiya) wrote:

That's interesting because I never intuitively understood the use of inject

This is bastardized from Smalltalk. In Smalltalk, method names consist of multiple words and the arguments are written in between the words. In Smalltalk, the method is called inject:into: and is called like aCollection inject: aValue into: aBlock, i.e. you inject an accumulator into a block that is executed for each element. This a) makes sense, and b) fits with the "in-joke" of naming all of Smalltalk's collection operations using names that rhyme (inject:into:, collect:, reject:, select:, detect:). Ruby is heavily based on Smalltalk, so it is generally expected that newcomers to Ruby will be familiar with Smalltalk's collection operations, therefore the slightly unusual names.

However, the meaning of "injecting an accumulator into a block" gets lost because in Ruby, we cannot write it that way, and so we lose the "into" from the name.

[I] always now use reduce, which […] has long been a concept in functional programming.

Note however, that at least in some programming languages, reduce is a restricted version of a fold which has a restricted type signature and only works on non-empty collections. In particular, in Scala, reduce is equivalent to Ruby's inject with only a block argument, and fold is equivalent to Ruby's inject with an explicit start argument. (In ECMAScript OTOH, reduce is the general version.)

reduce […] was (I believe) created by Haskell (the person and programming language)

Actually, Haskell calls the general version fold and the restricted version fold1 (because it requires at least one element, and will take element number 1 as the accumulator).

To me it says that an array of numbers (items) will be reduced|collapsed into a single value based on the given operation.

This idea of "reducing to a single value" is unfortunately somewhat misleading. A lot of people I talk to think that fold can only be used for summing, because they don't understand that a) the "single value" can be a different type from the element type and b) the "single value" can be arbitrarily complex, e.g. an array, a tree, an instruction sequence, etc.

In fact, fold is a general method of iteration, it can do everything that a loop can do. A compiler is simply a fold over the AST, for example. (The restricted version, i.e. what Haskell calls fold1 and Scala calls reduce OTOH is not general.)

Or, in short: naming is hard :-D