WIP/RFC: make find, filter, count more consistent

[rfourquet]

This is about adding the method count(A, value), as count(x -> x==value, A) is frustratingly verbose and slow. Then it is tempting to homogeneize a group of functions which can have those three methods:

1. f(pred, A) -> pred is applied to all A elements
2. f(A, val) <==> f(x -> x == val)
3. f(A) <==> f(x -> x != 0)

findnext and findfirst already have them, count had only 1. (and 3. via countnz), find had 1. and 3.

• I started applying the same for any and all, but then it is conflicting with any(A, dims) taking dimensions. This seems OK to leave it as it is (at least for any(A, value) <==> value in A).
• if A is a Dict, I chose to interpret filter(A, value) as comparing value to the values of A, not its keys. But then Regex makes the opposite choice, which I find surprising: filter!(r::Regex, d::Dict) = filter!((k,v)->ismatch(r,k),d). WDYT?
• findn and findnz would be happy to have those methods added too, but findnz looks like it finds non-zeros, so it should be renamed in this case. What does the n in findn stand for?

If this makes sense, I will add some tests before removing WIP.

[mortenpi]

I just discovered this PR and would like to bump it, since I feel that this would be a nice improvement to this set of functions. As a use case, I was looking for a findn(M::Matrix) -> (is,js) function that would take a generic predicate (i.e. a 1. version of findn), but that does not exist at the moment.

Just my two cents on the find* methods:

• find returns the linear indices, whereas findn finds the subscripts. My interpretation of the n in the name then would be "n-dimensional", or something like that. But perhaps there is a better name for these functions? findsubs?
• findnz finds the non-zeroes, just like find and findn, but also returns the values. While nz there quite clearly means "non-zeroes", I could imagine reinterpreting it as "find n-dims + values", with the analogy z = f(x,y) from mathematics. findnz also only seems to work with matrices at the moment, but I see no reason why it shouldn't work with general ND arrays.

Could the find methods be generalized then with the following semantics?

• find -- returns the linear indices
• findn -- returns the subscripts
• findnz -- returns the subscripts + values

with the method signatures as proposed before?

[rfourquet]

This is been solved somewhere else.