mean for tuples (iterable collections)

[WestleyArgentum]

I've stumbled missing this a couple times, I think it's reasonable

[WestleyArgentum]

Also: https://groups.google.com/d/topic/julia-dev/BNhPU9sG5Io/discussion

[StefanKarpinski]

So I just added an even more general version that only requires being able to iterate something without numel. This works, for example, for a task:

julia> t = @task for i=1:100
           produce(i)
       end
Task

julia> mean(t)
50.5

However, it raises some issues for me about count and composability of reducers since mean should just be composed from sum and count. One obstacle to this is count is currently used in a very different and – for me – unexpected way; another is that it's unclear how to do this composition over general iterables.

[WestleyArgentum]

Are you referring to the count(iter) used to "Count the number of boolean elements in itr which are true rather than false"?

Because I'm not a huge fan of that function. I do recognize the flexibility, I just get exasperated writing predicates that turn integers into bools.

[StefanKarpinski]

Yeah, that's a really old definition from before booleans were basically just Uint1 like they are now. Now it makes sense to use sum or nnz for this functionality. I think that count should be a generic reducer that counts you the number of elements in any iterable collection. However, there's some overlap with the meaning of length and numel then.

[WestleyArgentum]

I think it would overlap completely with numel, wouldn't it? If so, why not ditch numel.

And how exactly are numel and length different?

[StefanKarpinski]

Currently numel is an alias for length but once upon a time, in the tradition of Matlab, length of an array was max(size(a)), so numel(a) was necessary to get the actual number of elements for linear indexing. I feel like defining length of general iterables so that it consumes all the elements is a dangerous idea – to me length implies that you can know ahead of time what the size of something is, whereas count, being also a verb like sum, means it's expected that you may consume the input.

[StefanKarpinski]

cc: @JeffBezanson

[WestleyArgentum]

Ok, so doesn't it make sense to replace numel with count and either git rid of length or define it like they did in Matlab?

[WestleyArgentum]

Oh, and that other mean looks great, so I don't think we need this anymore lol

[StefanKarpinski]

No, I think it makes sense to ditch numel in favor of length and make count be a reducer that actually counts elements in an iterable. We can put count(a::AbstractArray) = length(a) for efficiency.

[StefanKarpinski]

For the record: 67f7d25.

[WestleyArgentum]

Ah, think I see what you were saying.

I was thinking just in terms of ease and figured that count could be implemented as length would have been and that people would assume that it does the most efficient thing given whatever circumstances.

But it could be useful to know precisely when you'll be counting as opposed to returning a known length.