Skip to content
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

Closed
Bouni opened this issue Feb 21, 2024 · 5 comments
Closed

[Bug] Bruteforce applies cuts a second time #63

Bouni opened this issue Feb 21, 2024 · 5 comments
Labels
bug Something isn't working

Comments

@Bouni
Copy link
Contributor

Bouni commented Feb 21, 2024

The different solvers return different results

Bruteforce:

grafik

FFD:

grafik

The FFD result is orrect in my opinion. 2x 495 = 990 + 6 = 996 => Two pieces should fit into one stock of 1000

I 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.

@ModischFabrications
Copy link
Owner

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.

@Bouni
Copy link
Contributor Author

Bouni commented Feb 22, 2024

🤔 Ok, havn't checkt to many variants of bruteforce against FFD to be honest.
We should defenitely implement material utilisation into the result, with that we can compare both algorithms and can probably implment some random input comparison benchmarks.

@ModischFabrications
Copy link
Owner

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.

@ModischFabrications
Copy link
Owner

Hey, any progress here? I might look into it the next few weeks, together with #52

@ModischFabrications ModischFabrications changed the title Inconsistent results for Bruteforce and FFD [Bug] Bruteforce applies cuts a second time Mar 17, 2024
@ModischFabrications
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants