-
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
[Bug] Bruteforce applies cuts a second time #63
Comments
Brute force might apply the cut weight a second time, but haven't checked. Might also be related to #59 Gapfill was my first (rather stupid) try if I remember correctly, it should have a comment somewhere. That one can definitely go. Bruteforce is important. It's definitely way slower, but it's the only way to get the perfect result. I only disable it above 11 entries because it will run too long otherwise. FFD is infinitely faster, but can be tricked, I think it can be up to 50% worse. |
🤔 Ok, havn't checkt to many variants of bruteforce against FFD to be honest. |
Bruteforce isn't very complex, it's really just testing every single combination, giving out the best one. That's the simple reason it can guarantee the best outcome. I think I have some basic benchmarks in the units tests, I think I actually use the remaining length to evaluate the results of bruteforce. |
Hey, any progress here? I might look into it the next few weeks, together with #52 |
I found the old benchmarks, not much to see there: 18d760b I created new tests in test_large , we can add random inputs there if you want. The difference is pretty irrelevant though: <8 entries are done instantly and might as well be perfect with bruteforce, >11 entries take too long for bruteforce and can only be solved with FFD. |
The different solvers return different results
Bruteforce:
FFD:
The FFD result is orrect in my opinion.
2x 495 = 990 + 6 = 996
=> Two pieces should fit into one stock of 1000I would propose to ditch the Bruteforce algorithm altogether as it doesn't matter if the FFD is sub milliseconds slower when used for < 10 items. Above that threshold the FFD comes into action anyway and that way we do not have to maintain two different algorithms.
The same goes for the gapfill algorithm.
The text was updated successfully, but these errors were encountered: