Sorry, I didn't respond to this. There's a lot to process for a request like this and just didn't get around to gathering all of our thoughts. So to answer your question:

In terms of feasibility, this is absolutely feasible. There are a few ways that this can break is if you do a "calculate by: average/ceiling/floor etc.." then set a max average/ceiling/floor respectively, it will be extremely slow because you're giving conflicting commands to the optimizer "find the highest average + limit the average to X". That is not THAT big of an issue, as we can solve that with changes to the interface.

The major issue comes from "how useful and useable is this feature going to be?" In terms of usefulness, users cannot adjust averages, floor or ceiling. These numbers are arbitrarily decided by us, as opposed to salary which is decided by the DFS site. Adding a minimum constraint to things like floor/average/ceiling will heavily penalize for using some of the most important value plays (low priced bench players with big opportunity). I don't exactly see a use for adding a ceiling for any of these values. Maybe you can chime in on why you believe this feature would give users an edge against non-FC users.

Then there's the issue with usability. In terms of salary, users have a intuition what restricting the salary to lineups over 49000 vs lineups over 49500. We have a hard limit that's known for the salary in place. In terms of average, floor, ceiling, it is not clear in any way what a minimum floor/average/ceiling of 150 points would mean. It is extremely difficult to determine what "good" bounds are. And these values will be wildly different slate to slate/day to day. Bad bounds come in two forms: overly lenient and overly restrictive. Overly lenient bounds take up computation resources and does nothing. These values need to be added into the optimization problems, and do nothing in changing the solutions that come out. Overly restrictive bounds will cause the solver to give users errors (especially when combined with exposure/uniqueness constraints) and can be frustrating to figure out what's causing the solver to not be able to find the number of lineups that were initially asked for.

All in all, it's that [i]could[/i] be added, but our current feelings is that it [i]shouldn't[/i] be added. Again, sorry about not replying sooner, it was a request that took a lot of consideration. If you believe that this feature would make our users better players, we'd be happy to hear your counter arguments.

It is true that the best lineup(s) are often projected lower (also maybe lower average, lower ceiling/floor what have you) than the optimal lineup. However, that is not in conflict with the statement that the optimal lineup usually performs better than suboptimal lineups. Because there are far more lineups with lower total average (close to the mean), than lineups with high total averages. So the probability of the BEST lineup having a (near average) total average is much higher than the best lineup having a very high total average. Simply because there could be hundreds, thousands, millions of times as many lineups with a lower total average. HOWEVER, the lineups with higher total averages will perform better than the vast majority of lineups with lower total averages because there are so many that will be really really bad, but these are hidden from you in lineup rewind because you're only looking at the top ACTUAL scores.

Of course this is the same with salary, lineups with a salary of 50k tend to do better than lineups with a salary of 49k, but very often we find that the top lineup is a lineup with a lower total salary. This is because there are more ways to make 49k lineups than there are 50k lineups (usually). So why do we implement salary constraints but not average/floor/ceiling?

The first reason, as previously mentioned, is that the users are very aware of where the bounds are. They get a good intuition for what setting the salary cap to 49.5k means. But that doesn't hold true for setting the average score cap to lets say...250 points.

The second reason is that have a very strong feeling that DFS players actively try to spend all of their salary cap. Even though salary is (somewhat) arbitrarily assigned by the DFS sites, players feel better about a lineup that uses all their salary. Avoiding max salary lineups does decrease the chance of your lineup being replicated in GPPs so there's some game theory edge. This is not likely to be true for average, and definitely not true for "FC floor/ceiling projections", because in order to maximize average score, you would need an optimizer, which isn't used by most DFS players. And of people using optimizer, I imagine very few try to "maximize" the average. They'll probably submit lineups that have high average scores, but not optimal, so if you're trying to avoid those lineups by capping averages to something lower than their already suboptimal values, you're probably in a dangerous zone where there are many many many low quality lineups. And the reason why allowing caps on floors/ceilings definitely won't give you a "game theory" edge is because unlike salary and average, FC floor/ceilings aren't available to everyone.

Third, salary cap is already an necessary constraint, so changing the max from 50k to 49.5k does not affect the solve speed. But if you add a constraint such as total average cap, then you're adding whole new dimension of constraints that will make the computation slower. We're not opposed to adding constraints that may speed the solves down (we've done it many times), but we are very hesitant to add them if they don't provide a clear benefit to users.

Here's an alternative solution, since what you're saying is "projections are good and all, but clearly there's uncertainty so I want lineups that doesn't rely solely on projections". Normally, that's what the other constraints are for, exposure, stacking, groups etc... But if you just want to account for projection uncertainty, just add some randomness. This will give you lineups that you may not get just optimizing on projections, and as a bonus it actually speeds up calculations. And if you feel like randomness doesn't give you control,I would argue that it gives you as much control as setting an arbitrary cap on total average/floor/ceiling would.

I want to emphasize that we really really appreciate our users making suggestions and even debating with us. We're currently not considering this feature because we're not currently convinced that it's a useful feature. If you or anyone else make a good counter argument for implementing the feature, we'd be happy to revisit it. Many times, new features that we come up with ourselves draw inspiration from feature suggestions that we turn down because they provide us with insight on what our users want.

In terms of a "sandbox" server, there may be security issues with that, but the main concern is we simply don't have the personnel to implement features on whim. As even with small changes like this, there is a lot of bug testing that needs to be done.

However, we are considering a bunch of features that will further increase the versatility of the tool which may encompass this request as well. But that's further down the pipeline as we need to figure out the specifics, which is why we're being very vague.