Progressive overload algorithm

[WhyAsh5114]

Overload is not as simple as I thought

In v2 I used the basic work volume formula of reps * sets * load, and aimed to improve this total by a fixed percentage every microcycle. As @patrick-b-c mentioned in #33, this formula is too primitive as it does not consider %1RM.

The formula assumes a 100kg deadlift for 10 reps is the same as 200kg for 5 reps, which is not the case.

A different formula

$$R_{2}=\frac{M_{2}\left(-a+r_{1}+R_{1}-37\right)}{FM_{1}}+a+37-r_{2}$$

So he did suggest a better adjusted Bryzcki formula for overloading, I tried this with a few examples and it does seem to work well, so for now I plan to use this as the primary way of progression for all types of sets, other suggestions are also welcome of course.

Everything the algorithm should do

• Progress through the rep range, increasing load when reached its end
• Adjust RIR as the mesocycle progresses
• Increase sets according the the volume changes set in the mesocycle
• Adjust rate of progression per exercise according to performances across mesocycle
• Increase load if exercise progression is set to load first feat: Remove preferred progression variable #80

For later

• Automatic regression detection #81
• Suggest localized deloads or full deloads as seen fit

[yzee-tech]

So I'd like to suggest an addition to this. In cases where the user doesn't end up doing exactly what the algorithm recommends, in terms of progression (perhaps doesn't get as many reps / weight as the algorithm recomments), you could calculate the difference between predicted and actual, and use that as an adjustment factor for future recommendations. This idea could defnitely get complicated, so probably better as a Phase 2.

[WhyAsh5114]

Adjust rate of progression per exercise according to performances across mesocycle

This is planned for v3 in this issue itself. I was thinking of just averaging the past performance changes with the current value of progressive overload for the mesocycle.

There are definitely other techniques with their own merits like smoothing functions which might offer better predictions, still exploring it at the moment.

[patrick-b-c]

Great to know the project moves along, and that you could use my suggestion.
I'll follow the project on the side line, feel free to tag me, if you have any questions.

[Testah2024]

Was the "feedback" implementation removed for V3?
I thought it would have had some kind of slight influence on the algorithm to determine your future sets based on your feedback, but after using V3, this feature seems to have been removed?

[WhyAsh5114]

Was the "feedback" implementation removed for V3? I thought it would have had some kind of slight influence on the algorithm to determine your future sets based on your feedback, but after using V3, this feature seems to have been removed?

Yeah, I was originally planning to add it, but after some more thought and consideration I decided not to. The reason was because its a bit too subjective.

I think I am basing my decision off of some of Menno Henselman's YouTube videos IIRC where he said something along the lines of our feelings aren't the best indicator for changes to a program. (I watched this quite some time ago, so maybe I misinterpreted)

And I kinda think that's true, so I decided to use performance changes over time as the sole indicator for volume change, which is also something Dr Mike Israetel's kind of videos support.

RP uses performance changes and soreness together to determine whether or not to add sets to the next workout. I simply removed the soreness part as I thought its redundant. If soreness is indeed hampering your workouts, it would reflect in the performance changes (either by a reduction in RIR at same loads, or actually unable to meet the set overload percentage), and the app can then use this performance drop (or non-ideal increase) to determine whether or not to increase sets.

So my TLDR reasoning:

• For the Joint Pain rating, it can simply be kept as a note on the exercise itself.
• Stimulus/Pump is something that's too subjective (based on Menno's video on Pull ups, I think)
• Soreness and Workload are redundant as they are just a proxy for performance changes (which we can measure directly)

I am open to suggestions of course, there might be some merits for including these metrics, this was just why I didn't implement them for now. If people actually want it, I can add it as an optional feature after v3-stable.

[WhyAsh5114]

Most of this issue's tasks have been completed, the advanced deloading stuff has now been moved to v3.1