CODEWITHSUNDEEP
haskellfunctional-programming
missingfaktor
missingfaktor

Reputation: 92026

Counting number of elements in a list that satisfy the given predicate

Does Haskell standard library have a function that given a list and a predicate, returns the number of elements satisfying that predicate? Something like with type (a -> Bool) -> [a] -> Int. My hoogle search didn't return anything interesting. Currently I am using length . filter pred, which I don't find to be a particularly elegant solution. My use case seems to be common enough to have a better library solution that that. Is that the case or is my premonition wrong?

Upvotes: 52

Views: 46652

Answers (6)

LLD
LLD

Reputation: 1

I'd do manually

howmany :: (a -> Bool) -> [a] -> Int 
howmany _ [ ] = 0
howmany pred (x:xs)  = if pred x then 1 + howmany pred xs 
                       else               howmany pred xs

Upvotes: -1

Roman Czyborra
Roman Czyborra

Reputation: 127

No, there isn't!

As of 2020, there is indeed no such idiom in the Haskell standard library yet! One could (and should) however insert an idiom howMany (resembling good old any)

howMany p xs = sum [ 1 | x <- xs, p x ]
-- howMany=(length.).filter

main = print $ howMany (/=0) [0..9]

Try howMany=(length.).filter

Upvotes: 0

JayJay
JayJay

Reputation: 592

This is my amateurish solution to a similar problem. Count the number of negative integers in a list l

nOfNeg l = length(filter (<0) l)
main = print(nOfNeg [0,-1,-2,1,2,3,4] ) --2

Upvotes: 3

Louis Wasserman
Louis Wasserman

Reputation: 198023

The length . filter p implementation isn't nearly as bad as you suggest. In particular, it has only constant overhead in memory and speed, so yeah.

For things that use stream fusion, like the vector package, length . filter p will actually be optimized so as to avoid creating an intermediate vector. Lists, however, use what's called foldr/build fusion at the moment, which is not quite smart enough to optimize length . filter p without creating linearly large thunks that risk stack overflows.

For details on stream fusion, see this paper. As I understand it, the reason that stream fusion is not currently used in the main Haskell libraries is that (as described in the paper) about 5% of programs perform dramatically worse when implemented on top of stream-based libraries, while foldr/build optimizations can never (AFAIK) make performance actively worse.

Upvotes: 49

MathematicalOrchid
MathematicalOrchid

Reputation: 62818

Haskell is a high-level language. Rather than provide one function for every possible combination of circumstances you might ever encounter, it provides you with a smallish set of functions that cover all of the basics, and you then glue these together as required to solve whatever problem is currently at hand.

In terms of simplicity and conciseness, this is as elegant as it gets. So yes, length . filter pred is absolutely the standard solution. As another example, consider elem, which (as you may know) tells you whether a given item is present in a list. The standard reference implementation for this is actually

elem :: Eq x => x -> [x] -> Bool
elem x = foldr (||) False . map (x ==)

In order words, compare every element in the list to the target element, creating a new list of Bools. Then fold the logical-OR function over this new list.

If this seems inefficient, try not to worry about it. In particular,

  1. The compiler can often optimise away temporary data structures created by code like this. (Remember, this is the standard way to write code in Haskell, so the compiler is tuned to deal with it.)

  2. Even if it can't be optimised away, laziness often makes such code fairly efficient anyway.

(In this specific example, the OR function will terminate the loop as soon as a match is seen - just like what would happen if you hand-coded it yourself.)

As a general rule, write code by gluing together pre-existing functions. Change this only if performance isn't good enough.

Upvotes: 6

ehird
ehird

Reputation: 40787

No, there is no predefined function that does this, but I would say that length . filter pred is, in fact, an elegant implementation; it's as close as you can get to expressing what you mean without just invoking the concept directly, which you can't do if you're defining it.

The only alternatives would be a recursive function or a fold, which IMO would be less elegant, but if you really want to:

foo :: (a -> Bool) -> [a] -> Int
foo p = foldl' (\n x -> if p x then n+1 else n) 0

This is basically just inlining length into the definition. As for naming, I would suggest count (or perhaps countBy, since count is a reasonable variable name).

Upvotes: 7

Related Questions