Tolerate representation noise in the presolve infinity sentinel - #95
Open
bodono wants to merge 1 commit into
Open
Tolerate representation noise in the presolve infinity sentinel#95bodono wants to merge 1 commit into
bodono wants to merge 1 commit into
Conversation
_presolve dropped inequality rows with b >= 1e20 using a strict comparison, so sentinels stored with ULP- or float32-level error (e.g. 9.999999999999998e19 -- as found in several Maros-Meszaros benchmark files) were classified as genuine finite bounds and materialized as 1e20-magnitude rows that silently poison equilibration and residual scales. Drop anything within relative 1e-6 of the sentinel instead (covers float32 storage error ~1.2e-7 with margin; no genuine bound plausibly lives within one part in a million of 1e20).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
QTQP's own
_presolvehad the same off-by-ULP blind spot just fixed in the benchmark harness:b >= 1e20with strict comparison misses sentinels stored with ULP or float32 representation error (e.g.9.999999999999998e19, exactly what several Maros–Mészáros files contain), materializing 1e20-magnitude rows that silently poison equilibration and residual scaling — the root cause of the historical 'chronic' benchmark failures. Drop anything within relative 1e-6 of the sentinel (covers float32 error ~1.2e-7 with margin). Test covers ULP-corrupted, float32-stored, and exact sentinels.