Pareto Front
en.wikipedia.org
en.wikipedia.org
I use conditional formatting to color cells according to the probability that I can lift them—if I lifted 50kg for 10 reps then I can definitely do 50kg for 9 reps, so that cell is green. But if e1RM(50,10) > e1RM(40,15) then I can probably do that too so it's light green. The visualization naturally becomes Pareto-like.
If I'm feeling strong I can aim for higher weight, lower reps. Or if I'm feeling weak I can close out a (weight, reps) that's below my current e1RM but I haven't accomplished yet. The end result is that I'm always "accomplishing" some sort of PR no matter how I feel.
I call this e1RM Bingo.
If pursued, good luck!
I'm not one to believe in all the one-shot hype, but this was pretty good.
Please don't make an app based on this.
Some nuance here: the latest research shows that proximity to failure is the main hypertrophy driver regardless of load and rep count; high rep count makes proximity to failure harder to gauge; so high load/low reps close to failure is probably better for hypertrophy (there are other good reasons to do higher reps/lower load work though)
If you want the most 'optimal' form of this (aka, hell on earth), you should purchase a rowing machine. Being able to engage with very aggressive, full-body exercise every single day without exceptions is almost like cheating biology. You can maintain a 2-3x VO2 max premium over your peers with very little risk of injury.
My main finding for “pick whatever weight you want today” was that picking a lot of different weights made the curve less identifiable, so my latest iteration encourages you to pick a ladder for a few sentinel exercises per mesocycle in order to improve the statistical power. In addition, strength improves more quickly at >80% of 1RM, and hypertrophy depends on proximity to failure, so if you pick a lower weight, you really need to go to failure, which burns you out for the rest of your session, where leaving 1-2 reps in reserve is probably sufficient for hypertrophy and leaves a lot more gas in the tank for the rest of the session. Definitely open to suggestion/discussion here.
https://curvefit.app (it runs on Cloudflare free tier, so I won’t have to start running ads or charging until I hit a couple thousand users)
But they go even a step further, they extend into 3 dimensions to also add body weight as a variable. So your graph would really have to be a 3D volume. Because different levels of body weight have different capabilities.
There are weight x rep combinations that have a e1rm of 80kg, 85kg, 90kg, and so on.
These are just equal elevation contours through the e1rm(x, y) function.
The Pareto concept doesn't require that we calculate a function of all the dimensions and find contours; that sort of thing is not involved.
But we could apply it here like this. Suppose we conduct a weight lifting contest as follows: contestants can lift any weight any number of times, and record the weight and reps.
Then, how do we rank the results to find a winner, or winners? We have multiple dimensions, not a single dimension like "seconds to run 10 km".
We can find the Pareto front set of the performances by eliminating all that have been dominated. A lift is dominated if another lift is no worse (no less weight, and no fewer reps), and strictly better: eight the weight is higher, or there are more reps, or both.
We then end up with undominated winners, e.g. there could be three like this: { (100kg, 1), (80kg, 2), (70kg, 5) } but (70kg, 4) would not belong, due to being dominated by the third one, and (90kg, 1) would not due to being dominated by the first. The middle one is not dominated by either: though it's less weight than the 100kg, it is more reps, and though it is fewer reps than the 70kg, it is more weight.
Given the Pareto front set, if we want to determine a single winner, we need a function to reduce the parameters to a single value. (The function should be such that if we included the eliminated losers under that function, none of them would emerge winner over the Pareto front set). This e1rm function looks like it fits the bill.
If we have this function, we don't need the Pareto concept; we just run all the results through the function and pick the contestant(s) that maximize it.
Maybe in vein but did anyone already figure this one out? The closest I got was PT sans, open-licensed commissioned by the Russian ministry for communication (I found it surprising that a country that doesn't use Latin script made the best font!), but it's not widely shipped so you need to figure out how to include font files whenever you want to use it
ss02 disambiguation seems to be the one I'd be wanting to turn on, with tnum for monospace numbers being a good option as well that I hadn't even realised I wanted from a font!
Tabular numbers are awesome!
I think fontTools instancer could work here, though it’s a CLI: https://fonttools.readthedocs.io/en/latest/varLib/instancer....
"The Pareto Front today claimed responsiblity for...."
[1] - http://montypython.50webs.com/scripts/Life_of_Brian/8.htm
Anyways I'll namedrop Iosevka as perfect monospace font for working on 13" laptop
They apparently released Hyperlegible Next in 2025 which, flipping between tabs on Google Fonts (since the original website doesn't show the fonts), is nearly identical but has five new weight settings (nobody should imo ever use thin fonts though, it noticeably harms readability for me and my sight is only the tiniest bit below normal vision, but ok it's an option) and improved kerning (the original font had extremely little space between 'll', for example)
The 2025 version sadly doesn't ship with my version of TexLive, but the original (from 2020) already does so that makes it easy to use as well! Cool stuff, thanks for the tip :)
When explaining it to some coworkers, I stumbled on a fairly intuitive explanation: "I've run farther before, and I've run faster before, but I've never run _this_ far, _this fast."
There was some pushback about why not just call it a PR (personal record), but I would only use that term for fixed distances (1mi, 5k, 10k, etc.) or a consistent route that I've run many times before. Nobody would say "I set my 7.40 mile PR today." More importantly, it misses the comparison to all farther (and faster) runs—it's not exciting to set a 5k PR just because you've barely run that distance before, and the pace is actually slower that a 10k you've done.
(Had a Pareto run of 7.40 miles @ 6:28/mi last week!)
A point is Pareto so long as it is non-dominated—that is, you're not looking for dominating points, you're looking for points that are "no worse" than all others, in all criteria, when you consider that point as a reference.
So your Pareto Runs are indeed Pareto points. However, your run with your fastest possible speed, even if your distance was really bad, is also still a Pareto efficient point.
(Taking >= as more efficient here) By definition, the point A is Pareto if there is no point B such that in all criteria, B >= A, and for at least one criteria B > A. Take the run with the best speed. It is Pareto because we cannot find a single point B that satisfies both of these conditions. Your "Pareto Run" doesn't satisfy this set of conditions because it is worse in terms of speed, even if it has better distance than the max speed point.
The only way your Pareto runs would be the only Pareto points in your record is if they simultaneously hit maxima for distance and speed when compared to all other points. So, for them to be the sole Pareto point, the clause ""I've run farther before, and I've run faster before..." would have to be false! The point would have to break both your all time records to be the solitary Pareto point. With running, because of how speed and distance are related this will basically never happen.
The definition of Pareto efficiency is essentially negative in nature--it's not about finding specific dominating points, it's about finding points that are not dominated by any others on any criterion, period. All criteria are weighted equally in the search for Pareto points. It doesn't build in any weighting like considering maximum across criteria as "better" than points that only maximize one criteria. For a "biobjective" problem like your runs, the Pareto set will always contain the points (MAX, -) and (-, MAX)--they may not be unique over the criteria but there will always be at least one representative for each, I believe.
ChatGPT 5.6 Luna on the right (cheaper) cover most of the frontier, with a point for Deepseek flash, and higher performance overlapping heavily between 5.6 Sol and Fable.
That DeepSeek point will probably move back towards Luna as deepseek announced a "significant" price increase coming to their API [1], which kind of demonstrates that beating the Pareto frontier is where the difficulty actually is).
[1] https://www.bloomberg.com/news/articles/2026-08-06/deepseek-...
I think it's great and hope the price can stay the same.
Going from 81GB of weights to 79GB of weights can mean a 50% reduction in GPU capacity required.
If you can fit a model in just one GPU (or rack) as opposed to across an entire datacenter, the latency gains can be substantial too. If you can reduce token latency by half, that would double the amount of customers you could support.
As the number of objectives (dimensions) increases, the number of samples you need to cover the frontier increases exponentially. You will very rarely find solutions that actually dominate other solutions in many practical optimization scenarios. With 2 dimensions you have a 25% chance of domination. With 10 dimensions it's a .098% chance.
The most useful cases I've seen tend to occur where we just optimize for two things at once. The chances of domination are high, it's easy to visualize and very efficient to implement. As we get into higher dimensional spaces, things get weird really fast.
As you say, the most useful things happen in low-dimensional spaces.
The geometric problem of computing a d-dimensional Pareto set of cardinality n
https://en.wikipedia.org/wiki/Maxima_of_a_point_set
has a truly weird property not covered by the computational complexity discussion on that page. It says there's an algorithm achieving O(n log(n)^(d-3) log log n), which is true and also a lie. The algorithm that achieves that asymptotic form is a galactic algorithm; and not an ordinary one in the sense of "has a large constant multiplicative factor", but one with this property (I've never found any other algorithm which exhibits it):
The runtime is within a bounded constant factor of n^2, for all n up to some critical N whose size is exponential in d (I think it was exactly 2^d or something).
I.e. the runtime has "two shapes": it's purely quadratic up to a galactically-large constant, and thereafter has a transition into to a slower function. The asymptotic version in the textbooks isn't achievable in the real world (for all but very small dimension).
There's an elementary proof using generating functions.
edit to add: If anyone's curious about it, a simplified version of the recurrence relation that's enough to exhibit this behavior (you can instantly see it if you graph this numerically) is
f(n,d=0) = 1
f(n=1,d) = 1
f(n,d) = n + 2f(⌊n/2⌋, d) + 2f(⌊n/2⌋, d-1)I've built large, deep product evaluation frameworks, and it is 100% of the time a running argument with stakeholders, inside and out, "well you should have measured it this way" or "I think we should be targeting X not Y" or "why didn't you consider Z in the metric??"
The Pareto Front in practice is squishy, fuzzy, and often quite moist and moldy.
The 80/20 “rule,” as far as I know, is meant to be descriptive after the fact. It can’t be used as a planning assumption. To be fair to those managers, they don’t really mean to be rigorous. They are just trying to justify cutting scope.
Is your planet accepting immigrants? I think I'd like it there
If one option is at least as good on every relevant dimension and better on one, just pick it. That's not really a trade-off, and it shouldn't need escalation. Eg, if two SaaS tools cost the same and have similar support, but one fits your use case better, you choose that one. Otherwise, you just suck at your job!
The interesting decisions only start once you're already on the frontier, where getting more of one thing means giving up something else. If the better tool costs 50% more, now you're trading capability against cost, and that may need sign-off.
Basically, everyone should be able to get to the frontier on their own. Coordination and arbitration at higher levels of the org / between different departments should happen on the frontier, where the trade-offs involve several people or teams.
The objectives are matching arguments to parameters.
A set of functions is identified among the candidates: those that are possible for the call at all, like having a compatible number of parameters.
Essentially, the overload rule says that the Pareto front set of candidates must contain one member, otherwise the call is considered ambiguous, and diagnosable rule violation.
The objectives being optimized are individual parameter positions, each in the dimension of suitability: being a better match.
One candidate is better than another if it is no worse a type match in every parameter, and strictly better in at least one parameter.
Is that trying to say:
"for every solution not in the set, there exists at least one objective such that at least one solution in the Pareto set beats that solution in that objective" i.e. every non-Pareto-front solution is beaten in some objective(s) by a Pareto-front solution, however it may be unbeaten in other objectives.
Or is it:
"for every objective in the system, every solution that is not in the set is beaten in that objective by one or more Pareto-set solutions."
Or is it:
"For every solution not in the set, there exists at least one Pareto solution which beats it in every objective."
For A to dominate B, A has to be at least as good (i.e. no worse) than B in every objective under consideration and A has to be strictly better than B in at least one objective.
Every solution in the Pareto front set dominates every solution not in that set: is at least as good in all optimization parameters and strictly better in at least one.
Among the front set, there is no mutual dominance: if we pick any pair out of the set, one may be better than the other in one or more parameters, but worse in one or more. If it were not worse in one or more than the other, that other would not belong in the front set due to being dominated.
Consider a space where we have two solutions. One is no worse than the other in every objective, and strictly better in one objective. Here, our Pareto front set contains that one solution and the other one is not in the set. Yet, the one not in the set is not beaten in every objective, just in that objective where the dominator is strictly better.
> Every solution in the Pareto front set dominates every solution not in that set
Not quite – for each solution not in the set, there exists a solution in the set that dominates it. For instance a front with (0,2) (1,1) (2,0) would not have (1,0). While (0,2) doesn't dominate (1,0), something else does.
It is a fact that the solutions in the front dominate all those not in the front, but the weakest statement we can make is that if a for a given solution B, we find another one A which is a dominant of B, then B is not in the front (regardless of whether or not A is).
Anyway, a couple of hours ago, I fixed up the informal wording in the article, which had misleading interpretations.
Matthias Ehrgott's books on multicriteria optimization explain Pareto efficiency very well without sacrificing rigor. I think they do a better job than this article.
Example: Which LLM gives me the best ELI5 explanations for a given price. https://evalry.com/benchmarks/explain-like-i-m-5-321
https://github.com/PatMyron/cloud#compute--memory-unit-price...
Of course, what's hard anyways when you have a good set of solutions that are pareto optimal, is to then choose between them. Especially as the dimensions (objectives) grow. In my example we can end up with many variants of strength/weight trade-offs that each are optimal, which one to choose?
“Chapter 4: The Seam Model”, Michael C. Feathers, Working Effectively with Legacy Code
It’s really that simple.
Eschew obfuscation.
The Pareto points are where you sacrifice the least of anything to get the most of everything.
There's the saying about buying computers. Good, Cheap, Fast, pick any two. That's where you would prioritise.
If someone makes something that better, cheaper, and faster, or even pretty close to the best on two of those and clearly better on the other. It's a Pareto point.
Over time computers are getting better, cheaper and faster (software notwithstanding). The leading edge of that advance of all of the things is the Pareto front.
> a Pareto front represents the set of solutions where no solution outperforms any other solution in the set at every objective
I do not believe you are correct when you say
> something that better, cheaper, and faster, or even pretty close to the best on two of those and clearly better on the other. It's a Pareto point.
Since that would outperform on every objective
GP's point that it's prioritisation does not seem incorrect to me. Prioritisation involves considering trade-offs of various approaches and deciding which aspects & attributes to optimise for, at the expense of others.
We choose our items/workflows/technologies/whatever, so we get the best/most efficient/most effective/whatever, across the widest possible set.
Sounds like prioritizing, to me, but I’m just a dumb hick, so I suppose I can be wrong.
Going for the Pareto is when you elect not to prioritise. It is explicitly deciding to not choose one property over another ant to keep everything as much as you can.
Getting to that point can be calculated (in some cases), but I suspect most folks get there by trial and error. Finding out what is effective, and what is not, and choosing what is effective, over what is not, until there's no longer a choice. That often becomes tribal knowledge, and is handed down. There's always someone trying to improve it, and when they figure it out, that gets added to the tribal knowledge. Basically, that's how nature does it, so there's some serious prior art. Natural Selection is brutal prioritization.
In Morocco, they used to announce the end of the Ramadan fast, by holding up a black thread and a white thread, and waiting until they could not tell the difference.
Then, they'd fire a cannon, and everybody would dig into some awesome soup. Sort of the same thing.
Say a race vehicle has acceleration, top speed as defining parameters. Some are slow but accelerate hard, others need a long time to reach very high top speeds. Others are in between, or just flat out bad at both.
The pareto frontier is the set of vehicles that are best: pick one from the frontier and you can be sure that for it's given top speed, none accelerate faster. And vice versa, pick one with a given acceletation and you are sure none have a better top speed
Some thing is "pareto optimal" when there isn't another thing that's AT LEAST AS GOOD in ALL measures, and BETTER in at least one way. For example, if we say there are no ties (for simplicity), then the cheapest language model is pareto optimal; the fastest model is pareto optimal; those which score highest on each benchmark are pareto optimal; and so on.
Tradeoffs can also be pareto optimal: for example, if the cheapest model is also slow, then there will be more pareto optimal models which are "cheapest for their speed"; and so on for other tradeoffs (e.g. fastest that achieves a certain benchmark score; cheapest model with open weights; etc.).
If you're making a decision about which thing to choose, you only need to care about those in the pareto front (since, by definition, anything that's not pareto optimal is objectively worse on at least one measure).
Pareto optimality does not compare one measure against another: something that's 10000x slower can still be pareto optimal, if it's 1% cheaper than the alternatives. To pick a "best" thing, you could give a weight/importance to each measure, and combine them into an overall score: but that's subjective, and might vary between people and tasks. In contrast, focusing on the pareto front is a way to ignore those things that will never be the best, regardless of weighting.
Mapping the cost of something (like an algorithm), and the time it takes (so lower is better for both). 1, 3 and 5 are all optimal in their own sense. No one is strictly better than the other, just different tradeoffs you have to choose yourself. However, you would never choose 2, because for a lower cost you could get the same result choosing 3. Same with 4, 6 and 7, they all have something that's both faster and at the same time just as cheap you could choose.
A pareto front is a bit like the classical "fast, cheap, good, choose 2". There are always tradeoffs, but if something is both slow, expensive and not better than something that's faster and cheaper, it's a bad choice, and thus not on the "pareto front".