Love it! I get your point much better now. I'll be using it in the future :).
Re Iterators, yes, your guess is spot on---it's those pesky tuples (which are way better than they used to be, see https://github.com/JuliaLang/julia/pull/4042). In high performance code, iterators from Iterators are usually a bottleneck. The recently-added iterator macros can sidestep that problem in some circumstances, but not without internal changes. Perhaps one option would be to explore using them more widely in Iterators? --Tim On Friday, August 15, 2014 09:37:12 PM Rafael Fourquet wrote: > > I've not used NumericFuctors so I can't comment on your main question. If > > it's of any use, there's an entirely different approach (more of a dirty > > trick, really) to inlining functions passed in as arguments. Here's a gist > > that shows the trick: > > https://gist.github.com/timholy/bdcee95f9b7725214d8b > > Thanks Tim, it is useful! by making more explicit the relevance of the > constructor trick: > > type sinc_plus_x end > sinc_plus_x(x) = sin(x)/x + x > > function sumf{F}(::Type{F}, x::AbstractArray) > s = 0.0 > for xs in x > s += F(xs) > end > s > end > > The above sumf is conceptually exactly the same as the one in your gist > (and so achieves the same performance), only it delegates the > meta-programming stuff to the compiler :-) > > Unfortunately, I failed to find a more general efficient solution, in the > vein of > sum(imap(sinc_plus_x, x)) > where imap is an iterator similar to the one in package Iterators.jl (or > python's imap): memory allocations are triggered, for no obvious (to me) > reasons (my guess would be tuples allocations in the next() implementation).
