-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weight equally good solutions by some metric #68
Comments
Only relevant for bruteforce! Other solvers won't look for other solutions |
…ecks, simplify tests with matrixes, remove cumbersome test fixtures, use simple typing, create and update SolverSettings, rework n_max checks to properly respect calculation times, major performance upgrade to bruteforce solver (closes #66), fix and include gapfill solver, prepare structure for #68 metrics
…ecks, simplify tests with matrixes, remove cumbersome test fixtures, use simple typing, create and update SolverSettings, rework n_max checks to properly respect calculation times, major performance upgrade to bruteforce solver (closes #66), fix and include gapfill solver, prepare structure for #68 metrics
…ecks, simplify tests with matrixes, remove cumbersome test fixtures, use simple typing, create and update SolverSettings, rework n_max checks to properly respect calculation times, major performance upgrade to bruteforce solver (closes #66), fix and include gapfill solver, prepare structure for #68 metrics
For #52 : Could prioritize solutions that use less infinite material with equal trimmings |
#52: Sort by fewest leftovers, e.g. with a min_cutoff_length or similar. |
Side-effect of trimming only solvers, can't really be caught at the moment: required = [500:1, 100:1] A human would just pick the 100 stock and pass it on, but the solver is going to use 500+100 to minimize trimmings. This is mathematically more efficient because 300 trimmings with 1 stock is less than 400 trimmings on 2. Future solvers could optimize for number of cuts and/or have adaptive weights based on {longest trimming, sum of trimmings, number of cuts, ...} instead, which would catch this, but could potentially leave more (but more usable) trimmings. |
nice to have: smarter ratings based on weights:
Bad solution
-> In the result both stock items are used, where it would be more efficient if all items were cut from the second stock item. It doesn't make a difference in waste, but a lot in handling. |
…est results to skip duplicates, sort results by biggest trimmings; update and fix tests, add test for #68; update v1.1.1
There are often solutions with identical trimmings. Current code just picks one at random, but there could be a setting to prioritize based on secondary metrics.
The text was updated successfully, but these errors were encountered: