I don't have the impression that reduce is slow. The reduce function that you're using is complicated and may have features that preclude optimizations, such as vectorization.
But perhaps more importantly, the reduce version, while probably very clever, is almost completely impossible to understand. I know what it's supposed to do, and I still cannot decipher it, while the straight loop is crystal clear and easy to understand. And almost as concise! On Wednesday, October 26, 2016 at 11:56:57 AM UTC+2, Gregory Salvan wrote: > > Sorry reduce was a bad idea, even if syntax is nice, it's really slow and > greedy. > > V1 can take advantage of @inbounds and @simd optimizations: > http://docs.julialang.org/en/release-0.5/manual/performance-tips/#performance-annotations > > I hope reduce will be optimized in future because here it expresses > rightly the problem we solve and has a nice syntax: > > mapeBase_v4(A::Vector{Float64}, F::Vector{Float64}) = reduce((0.0, 0), > enumerate(A)) do result::Tuple{Float64, Int64}, current::Tuple{Int64, > Float64} > current[2] == 0.0 && return result # guard clause > result[1] + abs( 1 - F[current[1]] / current[2]), result[2] + 1 > end > > unfortunately it's unusable ;) > > > 2016-10-26 8:01 GMT+02:00 Martin Florek <martin...@2bridgz.com > <javascript:>>: > >> Thank you everyone. v1 is very nice, as it turned out. I was looking for >> the magic of language Julia especially for the generator. >> > >
