Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Functions to add progress bars to for loops and apply functions #27

Closed
gaborcsardi opened this issue Dec 27, 2015 · 16 comments
Closed

Functions to add progress bars to for loops and apply functions #27

gaborcsardi opened this issue Dec 27, 2015 · 16 comments
Milestone

Comments

@gaborcsardi
Copy link
Member

E.g.

with_bar(
  for (index in sequence) block
)

and

lapply_with_bar(list, func)

Implementation is easy. The for loops need some non-standard evaluation.

@jefferis
Copy link

jefferis commented Jan 2, 2016

+1!

@gaborcsardi
Copy link
Member Author

Thanks. I am not completely satisfied with the syntax and the lapply_with_bar name, but if I cannot come up with anything better, I'll go with these, soon.

@jefferis
Copy link

jefferis commented Jan 3, 2016

A few alternatives:

  • lapply_progress
  • plapply
  • progressive_lapply
  • lapply_bar

@gaborcsardi
Copy link
Member Author

Alternative syntax ideas:

## This needs NSE to get `x`
progress > for (i in x) { }

## This knows `x` right away, no NSE needed
progress(x) > for (i in x) { }

## Similarly with *apply:
progress > lapply(x, function(i) { })

Maybe this is stupid, but how about

ooo == for (i in x) { }
ooo == lapply(x, function(i) {})

EDIT: this one also parses:

---O- for (i in x) { }
---O- lapply(x, function(i) {}

EDIT: with some hacks, even this seems possible:

for (i in progress(x)) { }
lapply(progress(x), function(i) { })

@gaborcsardi gaborcsardi added the bug an unexpected problem or unintended behavior label Mar 15, 2016
@gaborcsardi
Copy link
Member Author

> will not work, because there seems to be no way to capture the unevaluated argument (except for completely redefining >, which I don't want).

So we need to go with sg clumsier, e.g.

progress %P% for (i in 1:10) { print(i) }
P%P% for (i in 1:10) { print(i) }
add %[=]% for (i in 1:10) { print(i) }

Or the magical := operator:

progress := for (i in 1:10) { print(i) }

But the %% operators are really clumsy and heavy, they attract attention. The := is lighter, but it is already exported by data.table.

So I guess it has to be %%, and I can override how it looks in the IDE. Actually exactly %% might not be too bad:

progress %% for (i in 1:10) { print(i) }
progress %% lapply(1:10, print)

@gaborcsardi gaborcsardi removed the bug an unexpected problem or unintended behavior label Mar 15, 2016
@jefferis
Copy link

progress %% for (i in 1:10) { print(i) }
progress %% lapply(1:10, print)

These look good to me.

I haven't looked at the details at all, but would it be possible to use a pipe, perhaps like:

for (i in 1:10) %>% progress { print(i) }

# or reverse pipe

progress %<% for (i in 1:10) { print(i) }

@gaborcsardi
Copy link
Member Author

for (i in 1:10) %>% progress { print(i) }

This is not valid R syntax, I am afraid. It does not parse.

progress %<% for (i in 1:10) { print(i) }

This is probably possible, but I would need to redefine %<%, which is not ideal.

@gaborcsardi
Copy link
Member Author

Looks like %% does not work, actually. It has to be a conventional user defined %% operator then, e.g. %P% or %~~~%.

@jefferis
Copy link

Can you make a unary operator %progress% or %P% ?

%progress% for (i in 1:10) { print(i) }

@gaborcsardi
Copy link
Member Author

That's not possible, unfortunately. I could use ? or !, but neither are very good.

gaborcsardi added a commit that referenced this issue Mar 15, 2016
But a long way off, still.
@gaborcsardi
Copy link
Member Author

Work is going on in the https://github.com/gaborcsardi/progress/tree/decorator branch now.

@gaborcsardi
Copy link
Member Author

A relevant discussion: tidyverse/purrr#149

I quite like the functional form:

progressify(lapply)(seq, fun)

and maybe this does not even require NSE. We just create a new function that calls both the original function and tick().

But this does not work for for loops. I am not sure how much of a problem that is. Maybe

for (i in progressify(seq)) { } 

could work. It requires some tricks, though. Maybe we can just wait until the iterator type for loop arrives to R, probably in 3.4.0.

@kendonB
Copy link

kendonB commented Jul 8, 2016

I assume y'all are aware of this: https://github.com/psolymos/pbapply ?

I am using it and it works great for apply functions. Still no solution for parallel functions or dplyr::mutate / purrr::map

@gaborcsardi
Copy link
Member Author

@kendonB I have probably seen it, I am not sure to be honest.

@psolymos
Copy link

Just uploaded pbapply v1.3-0 to CRAN with parallel functionality.

@gaborcsardi
Copy link
Member Author

Implemented in cli.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants