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

[Feature Request] Automatically Use minReps When Using Rep Ranges #77

Open
youhavejameswoods opened this issue Mar 13, 2024 · 6 comments

Comments

@youhavejameswoods
Copy link

Today, using Rep Ranges seems to necessitate the need to use custom progression scripts. If one is using rep ranges, they would most likely consider success to be anywhere in and above the range (i.e., >= minReps).

Automatically leveraging minReps when Rep Ranges are in use would greatly simplify the code required to be written for lifting programs.

@astashov
Copy link
Owner

Usually you want to increase weight when you hit the upper limit though, right? Like the standard double progression - you have a range 8-12, and once you hit 12, you bump up the weight. Currently you can do it like Squat / 3x8-12 / progress: lp(5lb).

But you want to increase the weight when you hit min reps in the range ,right?

@youhavejameswoods
Copy link
Author

Yeah, my thought is that if I wanted to bump up the weight when I hit the upper limit, then I'd just use the single target weight rather than a range.

I'm personally using the ranges on the sets that follow the set with the highest weight/volume lifted - I like to increase after I hit the target on the big set, as long as my other sets that follow are somewhere between 7-9 (for example).

@youhavejameswoods
Copy link
Author

Is there a plan to implement this at some point in the future? Mainly asking because I’m considering transitioning my programs from the legacy versions to new, but I’ll hold off a bit if this is a future enhancement since it’ll cut down on custom code significantly (I think it’ll actually remove the need for any custom code for progressions for me).
Thanks!

@astashov
Copy link
Owner

Currently, if you use rep ranges with progress: lp, then it uses the top of the range to make a decision if you need to bump up the weight, and the bottom of range to make a decision if you need to reduce the weight. I.e. if you have Squat / 3x8-12 / progress: lp(5lb, 1, 0, 10lb, 1, 0), then it'll increase the weight if you hit 12 on all the sets, and will reduce the weight if at least one of the sets is below 8.

I think the logic makes sense, and frankly if I change it - it's going to be a breaking change for a lot of people. So, in your case I'd recommend to still use a custom progressions. Something like this:

Squat / 4x8-12 / progress: custom() {~
  if (completedReps[1] >= reps[1] && completedReps >= minReps) {
    weights += 5lb
  }
~}

That would make sure you hit the max rep on the first set, and the rest of the sets are at least within the rep range.
You could reuse the logic in all the rest of your exercises, like:

Bench Press /  4x8-12 / progress: custom() { ...Squat }

@youhavejameswoods
Copy link
Author

Thank you very much! That reminds me… I was thinking that it’d be useful to define the reusable custom progressions more generally, outside of exercises. It would help people from having to remember how progressions are defined per exercise.

For example, I’d like to name a progression “Increase by 5lbs after 1 success, decrease by 5lbs after 5 failures” - that way it’s very clear what custom progression I’m repeating when calling upon it. I may decide later that I want to wait until 6 failures for squats but not for all of the exercises that were reusing the progression.

@astashov
Copy link
Owner

You can kinda do that right now, with creating a non used exercise, and reuse its progress:

my_very_cool_progression: Squat / 1x1 / used: none / progress: custom() {~
  // your logic
~}

Bench Press / 3x8 / progress: { ...my_very_cool_progression: Squat }

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

2 participants