New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

_.count method #702

Closed
justin808 opened this Issue Sep 7, 2014 · 10 comments

Comments

8 participants
@justin808

justin808 commented Sep 7, 2014

Would it make sense for lodash to have a _.count method?

Like this: http://ruby-doc.org/core-2.1.2/Enumerable.html#method-i-count
I'd be happy to implement one and submit a PR if this is appropriate.

@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Sep 7, 2014

Member

Thanks for asking. This looks like a combo of a couple of existing methods.
There's _.filter & _.size which can be used to come to similar results.

We'll keep an eye on the popularity of the request.

Member

jdalton commented Sep 7, 2014

Thanks for asking. This looks like a combo of a couple of existing methods.
There's _.filter & _.size which can be used to come to similar results.

We'll keep an eye on the popularity of the request.

@nickperkinslondon

This comment has been minimized.

Show comment
Hide comment
@nickperkinslondon

nickperkinslondon Jun 10, 2015

👍 for _.count ( and _.countWhere)

I was surprised to find that these don't already exist! Wouldn't it be nice, when you just want to count something, to simply reach for the _.count() function?

Of course you can do it with "filter/length" but that seems a tiny bit awkward, and counting is such a simple and fundamental concept -- it deserves it's own function. ( plus, there's the performance thing -- you could implement it without creating a new array ).

nickperkinslondon commented Jun 10, 2015

👍 for _.count ( and _.countWhere)

I was surprised to find that these don't already exist! Wouldn't it be nice, when you just want to count something, to simply reach for the _.count() function?

Of course you can do it with "filter/length" but that seems a tiny bit awkward, and counting is such a simple and fundamental concept -- it deserves it's own function. ( plus, there's the performance thing -- you could implement it without creating a new array ).

@c-dante

This comment has been minimized.

Show comment
Hide comment
@c-dante

c-dante Mar 19, 2016

My only conflict is how count is useful in applications -- I'm trying to think of times where I want how many satisfy a predicate and not which -- I keep coming to UI concerns only.

Is there a meaningful algorithm or use case you can come up with that just wants to know how many and not which? Or rather, one such that you do not want the filtered set (either side)?

Edit:
Oh. We get _.sumBy. So here's your count:

_.sumBy(collection, (x) => pred(x) ? 1 : 0)

c-dante commented Mar 19, 2016

My only conflict is how count is useful in applications -- I'm trying to think of times where I want how many satisfy a predicate and not which -- I keep coming to UI concerns only.

Is there a meaningful algorithm or use case you can come up with that just wants to know how many and not which? Or rather, one such that you do not want the filtered set (either side)?

Edit:
Oh. We get _.sumBy. So here's your count:

_.sumBy(collection, (x) => pred(x) ? 1 : 0)
@jdalton

This comment has been minimized.

Show comment
Hide comment
@jdalton

jdalton Mar 19, 2016

Member

@c-dante Oh neat!

_.sumBy(collection, _.flow(pred, Boolean));
Member

jdalton commented Mar 19, 2016

@c-dante Oh neat!

_.sumBy(collection, _.flow(pred, Boolean));
@lindem

This comment has been minimized.

Show comment
Hide comment
@lindem

lindem Jun 8, 2016

Just stumbled across this (because I need to count predicate-satisfying values); I'd like to add that _.count(seq, predicate) is also self-documenting code. I think _.countBy() just doesn't achieve the same degree of simplicity, its return value always being an object. I am really surprised that there's opposition to this particular concept of just returning a number.
EDIT: That's 👍 for a simple _.count() returning a number.

lindem commented Jun 8, 2016

Just stumbled across this (because I need to count predicate-satisfying values); I'd like to add that _.count(seq, predicate) is also self-documenting code. I think _.countBy() just doesn't achieve the same degree of simplicity, its return value always being an object. I am really surprised that there's opposition to this particular concept of just returning a number.
EDIT: That's 👍 for a simple _.count() returning a number.

@jdalton jdalton added votes needed and removed wontfix labels Jun 8, 2016

@c-dante

This comment has been minimized.

Show comment
Hide comment
@c-dante

c-dante Aug 1, 2016

I'm for a mixin of:

_.count = _.sumBy(collection, _.flow(pred, Boolean));

Whether its implemented that way or not. It's pretty clear what would be expected from:

_.count(myNumbers, x => x > 5);  // I read this is, "how many of myNumbers are > 5

_.count(name.split(''), x => x === 'a'); // How many "a" are in name?

_.count(resturants, x => distanceFromMe(x) > 10mi); // How many resturants are within 10mi of my location

c-dante commented Aug 1, 2016

I'm for a mixin of:

_.count = _.sumBy(collection, _.flow(pred, Boolean));

Whether its implemented that way or not. It's pretty clear what would be expected from:

_.count(myNumbers, x => x > 5);  // I read this is, "how many of myNumbers are > 5

_.count(name.split(''), x => x === 'a'); // How many "a" are in name?

_.count(resturants, x => distanceFromMe(x) > 10mi); // How many resturants are within 10mi of my location
@mologie

This comment has been minimized.

Show comment
Hide comment
@mologie

mologie Aug 30, 2016

There also is an argument of efficiency to make here.

Most combined functions which achieve the behavior described in this ticket will build some kind of temporary object, which is then further evaluated for deriving the final count. Obvious examples are the filter+length and the map+sum approaches described above.

A more efficient implementation would only require a single integer for counting. This ticket therefore has my vote, because bits are precious.

mologie commented Aug 30, 2016

There also is an argument of efficiency to make here.

Most combined functions which achieve the behavior described in this ticket will build some kind of temporary object, which is then further evaluated for deriving the final count. Obvious examples are the filter+length and the map+sum approaches described above.

A more efficient implementation would only require a single integer for counting. This ticket therefore has my vote, because bits are precious.

@SmedbergM

This comment has been minimized.

Show comment
Hide comment
@SmedbergM

SmedbergM Nov 14, 2016

I'd upvote this too. _.sumBy(collection, predicate) works but is unidiomatic.

SmedbergM commented Nov 14, 2016

I'd upvote this too. _.sumBy(collection, predicate) works but is unidiomatic.

@gunar

This comment has been minimized.

Show comment
Hide comment
@gunar

gunar Mar 2, 2017

The predicate needs to return a number not a boolean, hence

_.sumBy(collection, _.flow(pred, Number));

gunar commented Mar 2, 2017

The predicate needs to return a number not a boolean, hence

_.sumBy(collection, _.flow(pred, Number));
@SmedbergM

This comment has been minimized.

Show comment
Hide comment
@SmedbergM

SmedbergM Mar 2, 2017

The predicate needs to return a number not a boolean

In a type-safe world, sure. But + coerces booleans into numbers, which is why I said it works.

SmedbergM commented Mar 2, 2017

The predicate needs to return a number not a boolean

In a type-safe world, sure. But + coerces booleans into numbers, which is why I said it works.

@lodash lodash deleted a comment from vance Dec 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment