Training Max vs True Max: What Lifters Should Know Before Programming

Why formula-based estimates need validation

Fitness calculators look simple from the outside. A user enters weight and reps, then the tool returns an estimated one-rep max. The technical challenge is that different formulas don’t behave the same way across rep ranges.

For example, Epley and Brzycki may produce close results at lower reps, but the gap can widen as reps increase. If I were building a strength calculator API in InterSystems IRIS, I’d start by treating each formula as a separate calculation strategy. A useful consumer-facing reference for this kind of comparison is the page explaining how to estimate your 1RM from submaximal lifts.

Basic calculator design

The data model does not need to be complicated. Each calculation request should record the lift, load, reps, formula, and output estimate.

Useful fields

• Athlete ID or anonymous session ID
• Lift type, such as squat, bench press, or deadlift
• Weight lifted
• Reps completed
• Formula selected
• Estimated 1RM
• RPE, if the user provides it
• Timestamp

This lets the application calculate a single result while also building a useful history for trends.

Formula strategy pattern

In ObjectScript, I’d avoid hard-coding every formula inside one long method. A cleaner structure would use separate methods or classes for each equation.

Example approach

• CalculateEpley(weight, reps)
• CalculateBrzycki(weight, reps)
• CalculateLombardi(weight, reps)
• CompareFormulas(weight, reps)

That final method can return all estimates side by side. This helps users see that a 5-rep estimate and a 10-rep estimate carry different levels of confidence.