A more accurate say to estimate 1RM (why this model works better)
hyu_
Most online 1RM calculators rely on linear or quasi-linear empirical formulas (Epley, Brzycki, Lombardi). These models assume a linear decrease in strength as repetitions increase. While convenient, this assumption does not reflect the actual fatigue mechanisms observed in resistance training.
Physiologically, force production under repeated effort follows an exponential decay, driven by metabolic fatigue and neural factors. A closer approximation of real performance is: (see image 1)
Model extensions
This calculator builds on the exponential model with several practical refinements:
Lift-specific fatigue constants (bench, squat, deadlift behave differently)
Individual calibration of k using two known sets: (see image 2)
(see image 3)
In practice, traditional formulas typically show 5–10% error outside narrow rep ranges.
Once calibrated, this model consistently stays within ~1–3% for low-to-moderate reps, reflecting both physiological realism and individual variability.
This approach replaces outdated linear assumptions with an exponential fatigue model, minimal but meaningful corrections, and forcing individual calibration. The result is a 1RM estimator that is both computationally simple and significantly more accurate for real-world training data.
Wayne Schuller
Dear Hyu, this is very provocative and interesting. I would love to provide new ways of calculating e1rm in Strength Journeys. What is the source of your images? Is there a paper I can read and implement from?
hyu_
Wayne Schuller
Thank you, I’m glad you find it interesting.
The model is something I developed myself rather than taken from a single paper or dataset. It’s built on top of the classic 1RM formulas (Epley, Brzycki, Lander, Lombardi), but with an added calibration layer.
I’ve already coded and tested the calculator. The core idea is introducing a fatigue coefficient k that is solved using two known submaximal sets from the same lifter and session. Instead of assuming a fixed reps-to-fatigue relationship, the curve adapts to the individual lifter and the specific context (exercise, rep range, proximity to failure).
From a math perspective, I treat e1RM estimation as an inverse problem with constraints, rather than a direct heuristic. Traditional formulas effectively assume an average population response; this approach fits the response locally to the athlete.
There isn’t a published paper at this point — it’s an engineering-driven model developed through implementation and comparison against existing calculators. I’m happy to share the equations, assumptions, or the current implementation if you’d like to review or test it further.
Wayne Schuller
hyu_ Would we need to have some more data points from the user for your model? e.g.: does the user need to provide reps in reserve judgement? It might be too complex for Strength Journeys as an app...
hyu_
Wayne Schuller
Good question. Additional data points are optional, not mandatory.
The model degrades gracefully. In its simplest form, it works exactly like a standard calculator using only load and reps (with RIR defaulting to 0 and a population-average
𝑘
k). In that mode, it’s no more complex than Epley or Brzycki.
When RIR is provided, it improves accuracy but isn’t required. Calibration using two known sets is an optional advanced path, not a hard requirement. If the user only inputs a single set, the calculator behaves like a conventional e1RM estimator.
From a UX standpoint, the complexity can remain hidden: basic users see a standard calculator; advanced users unlock higher precision. The math lives in the backend — the interaction cost doesn’t have to increase.
In short, the model is backward-compatible with existing workflows while offering a clear accuracy upgrade when more information is available.
Wayne Schuller
hyu_: hmmm I'll have to think about this more. Feel free to offer a patch and we could trial having a formula named after you! On of my goals is to make it easy for the user to road test the common formulae and find what fits them best and this can help with planning for competing.
hyu_
Wayne Schuller
That sounds great — I like that philosophy a lot.
I’m happy to provide this as a lightweight, optional patch rather than a core replacement. It fits well with the idea of letting users road-test different models and see what aligns best with their own performance.
From an implementation standpoint, it can live alongside the existing formulas as a “calibrated” option. With a single set, it behaves like a standard estimator; with two sets (and optionally RIR), it adapts to the individual. No extra friction for users who want simplicity, but more precision for those planning peaking or competition attempts.
I can package it cleanly (equations, constraints, defaults, and edge cases) so it’s easy to trial without committing to any UX changes upfront. If it performs well in the wild, it can earn its place naturally.
Happy to send over a patch and let real users decide.