You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if map, mapreduce, and reduce were supported with @progress, for example
squares =@progressmap(i -> i^2, 1:10)
prod =@progressmap((x,y) -> x * y, 1:10, -5:5)
sum_squares =@progressmapreduce(+, 1:10) do x
x^2end
sum_ =@progressreduce(+, 1:10)
I've looked through the source code and at first glance it seems like the _progress function will not support this without a small rewrite.
I would propose refactoring _progress such that it first tees the input expression to the appropriate use-case (for loop vs. comprehension vs. mapping function), after which we can have _forprogress, _mapprogress, etc. This is similar to the way ProgressMeter parses their @showprogress macro.
I took a shot at implementing this myself and came up with the following
function_mapprogress(name, thresh, ex)
L =length(eval(ex.args[3])) # get first collection sent to map
body = ex.args[2]
@gensym lastfrac frac val it count_var
m =@__MODULE__quote$m.@withprogress name =$name begin$lastfrac =0.0$count_var = Thrads.Atomic{Int}(0)
$(ex.args[1])($(ex.args[3:end]...)) do$it
$val =$body($it...)
Threads.atomic_add!($count_var, 1)
$frac =$count_var[] /$L
if$frac -$lastfrac >$thresh
$m.@logprogress$frac
$lastfrac =$frac
end$val
endendendend
using the above I was able to get progress to work for the case of map(x -> x^2, 1:10). It did not work with multiple ranges (eg map((x,y) -> ..., 1:10, -5:5)) and I didn't try writing up the reduce versions. The choice of using the atomic iterator was to make sure the call is thread-safe.
The text was updated successfully, but these errors were encountered:
It would be nice if
map
,mapreduce
, andreduce
were supported with@progress
, for exampleI've looked through the source code and at first glance it seems like the
_progress
function will not support this without a small rewrite.I would propose refactoring
_progress
such that it first tees the input expression to the appropriate use-case (for loop vs. comprehension vs. mapping function), after which we can have_forprogress
,_mapprogress
, etc. This is similar to the way ProgressMeter parses their@showprogress
macro.I took a shot at implementing this myself and came up with the following
using the above I was able to get progress to work for the case of
map(x -> x^2, 1:10)
. It did not work with multiple ranges (egmap((x,y) -> ..., 1:10, -5:5)
) and I didn't try writing up the reduce versions. The choice of using the atomic iterator was to make sure the call is thread-safe.The text was updated successfully, but these errors were encountered: