Skip to content

Conversation

@odow
Copy link
Member

@odow odow commented Aug 7, 2025

Closes #133

solutions = [SolutionPoint(X, Y) for (Y, X) in solutions]
return status, solutions
solutions_vec = [SolutionPoint(X, Y) for (Y, X) in solutions]
return status, filter_nondominated(MOI.MIN_SENSE, solutions_vec)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? In #133, we round the solutions to be integers but I think they are actually different points. Just slightly different due to floating points. Also, solutions is a Dict so the keys should be unique.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The list of solutions prior to filtering includes stuff like this:

 [1277.0, 991.0, 1077.0]
 [1277.0, 991.0000000000001, 1077.0]

Maybe we need to change if Y ∉ U_N[u][k] to be approximate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's what I was referring to. We could change it but that would be slower, right? We could allow this and change the test to check for rounded nondominated set. The tradeoff is to allow these approximately equal but ultimately distinct points and pay the price to solve extra scalarizations or check for approximately equality and avoid extra scalarazations. The cost of solving more scalarazations is not perhaps significant for knapsack but it could be for some other problem.

@codecov
Copy link

codecov bot commented Aug 7, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.72%. Comparing base (9363a93) to head (8c08a77).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #134      +/-   ##
==========================================
- Coverage   98.72%   98.72%   -0.01%     
==========================================
  Files          12       12              
  Lines        1101     1100       -1     
==========================================
- Hits         1087     1086       -1     
  Misses         14       14              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@odow
Copy link
Member Author

odow commented Aug 7, 2025

How's this?

@kofgokhan
Copy link
Contributor

I actually meant that checking for approximate equality could be slower but it will save scalarazations and I missed the fact that some points will be dominated.

@odow
Copy link
Member Author

odow commented Aug 8, 2025

approximate equality could be slower

Much cheaper than solving another LP.

I tried a similar change for KirlikSayin, but I ran into a bunch of errors (I think because of assumptions to do with the boxes, so I just filtered at the end.

@odow odow merged commit 515f7cc into master Aug 8, 2025
7 checks passed
@odow odow deleted the od/fix-133 branch August 8, 2025 01:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Numerical issue in TambyVanderpooten

3 participants