Modifying mapflodl in reduce.jl would make sum work:
function mapfoldl(f, op, itr)
i = start(itr)
if done(itr, i)
return Base.mr_empty(f, op, eltype(itr))
# instead of: error("Argument is empty.")
end
(x, i) = next(itr, i)
v0 = evaluate(f, x)
mapfoldl_impl(f, op, v0, itr, i)
end
This should be type stable for most types as eltype really should be
implemented based on type-parameters, right?
On Mon, 2014-06-30 at 10:08, iva...@gmail.com wrote:
> It is a bug (in my opinion, but others might disagree), but fixing this
> will have consequences for performance in some cases.
>
> Part of problem is that most users want sum to be fast, and that means it
> has to be type stable. That means that the type of the sum needs to be
> determined only based on the type of the arguments (not their value). This
> is often tricky to achieve.
>
> In this case, we can actually know that everything returned by the
> ValueIterator is `Int32`, which eltype(values(Dict{Int32,Int32}())) will
> reveal. The correct result for sum() will then be zero(Int32) + zero(Int32).
>
> Ivar
>
> kl. 10:48:09 UTC+2 mandag 30. juni 2014 skrev David Gonzales følgende:
>>
>>
>> I came across the following difference:
>>
>> In[]: sum(collect(values(Dict{Int32,Int32}())))
>>
>> Out[]: 0
>>
>> In[]: sum(values(Dict{Int32,Int32}()))
>>
>> Out[]: ERROR: Argument is empty.
>>
>> the difference is having an Array vs. an Iterator, but:
>>
>> In[]: typeof(values(Dict{Int32,Int32}()))
>>
>> Out[]: ValueIterator{Dict{Int32,Int32}}
>>
>> So the type of the iterator and hence the zero for the sum initialization
>> can be known and a 0 returned (as in the case of an array).
>>
>> Is this a bug or a feature?
>>
>>
>>
--
