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
We probably want this to be optional, mirroring purrr::map. I thought some dplyr ops had automatic progress bars if they took a substantial time at some point, but that doesn't seem to be the case now? We might look for experiences there.
We could likely add progress-by-version to the outer version loop fairly easily by replacing the group_map of the slide computation with a group_map that simply dumps the .x and .y to use, then doing a purrr::map over those forwarding a .progress arg that the user passes into epix_slide(). If we want something finer-grained updating after every slide computation (rather than after every version), or if we swap the outer&inner loops, we'd need to use cli progress bar utilities directly rather than via purrr, and would need to figure out how to handle an uncertain number of tasks to run (as the number of groups may increase from version to version).
(Progress bars that update every version will likely be biased in that later tasks will incorporate more data and likely run more slowly than earlier computations.)
The text was updated successfully, but these errors were encountered:
Request from @XuedaShen.
We probably want this to be optional, mirroring purrr::map. I thought some dplyr ops had automatic progress bars if they took a substantial time at some point, but that doesn't seem to be the case now? We might look for experiences there.
We could likely add progress-by-version to the outer version loop fairly easily by replacing the group_map of the slide computation with a group_map that simply dumps the .x and .y to use, then doing a purrr::map over those forwarding a .progress arg that the user passes into epix_slide(). If we want something finer-grained updating after every slide computation (rather than after every version), or if we swap the outer&inner loops, we'd need to use cli progress bar utilities directly rather than via purrr, and would need to figure out how to handle an uncertain number of tasks to run (as the number of groups may increase from version to version).
(Progress bars that update every version will likely be biased in that later tasks will incorporate more data and likely run more slowly than earlier computations.)
The text was updated successfully, but these errors were encountered: