Skip to main content
Data Science

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

6
  • 3
    $\begingroup$ Really interesting read, thanks for sharing. The softmax trick to enforce weights summing to 1 is elegant; it both strictly enforces weights summing to 1 and also simplifies the code. I am intrigued that the overcapacity loss was hampering performance. Not sure why that is - it seems to rear its head in the more complex cases you tried (in the simper cases it was exactly zero). Glad you have homed in on a solution that ticks all the boxes - nice work. $\endgroup$ Commented Sep 19 at 14:02
  • 3
    $\begingroup$ The overcapacity term would work if all machines would have the same cycle time, but unfortunately that's not the case. If the cycle times differs, a change of eg. +1% of utilization on one machine, corresponds to a decrease of only -0.5% on another machine. When the solution average ends up being greater than 100%, the "zone" between 100% capacity, and solution average capacity (eg. 110%), the lower portion of it (closer to 100%) ends up having lower loss value when the utilizations end up being non-uniform: i.imgur.com/fVDa1zv.png $\endgroup$ Commented Sep 20 at 14:07
  • 1
    $\begingroup$ On the other hand, passing the middle of the zone (going above 105%) yields the opposite effect, where the more uniform case ends up having the lower loss: i.imgur.com/FD9Wrm0.png Since the calculation has to pass through the first zone during solving, it gets stuck in that local minimum, and the solution ends up off-target, according to each machine's cycle time - lower time ends up getting higher utilization, and all utilization values are off the expected average. I realized that removing the overcapacity term gets rid of that zone, and the uniformity term is enough already. $\endgroup$ Commented Sep 20 at 14:11
  • 1
    $\begingroup$ I wonder whether it's an artefact of how overcapacity loss was implemented. The loss is suddenly introduced after the algorithm ends up in a bad place. It plays no role when the machines have valid capacities, and only kicks in when a machine's capacity exceeds 100%. Perhaps at that point it's too late to effectively correct for. A better approach might be to make it continuous, increasing as we approach the overcapacity threshold. Might steer the algorithm better overall, but could introduce issues of its own. You've done fine without it so may not be worth investigating. $\endgroup$ Commented Sep 20 at 14:32
  • $\begingroup$ It clearly cannot function together with uniformity, otherwise it keeps pulling towards 100%, while uniformity keeps pulling towards eg. 110%, and whichever machine ends up being closer to one of the two values wins. Below 100% average, uniformity will already pull down any machine going above 100% (meaning there's no need for overcapacity), and above 100% average, uniformity is also all we need to balance things out (meaning no overcapacity needed as well), so while the sole idea is sound, uniformity is just better to be used in all cases. $\endgroup$ Commented Sep 20 at 22:38