Fix missing_constant not suppressing min/max range errors in ASCII tables - #1664
Fix missing_constant not suppressing min/max range errors in ASCII tables#1664jordanpadams wants to merge 1 commit into
Conversation
…bles (#1660) In SpecialConstantChecker.sameContent(), BigDecimal values (used for ASCII_Real and other ASCII numeric field types) were being converted to Double then to a raw-bit-pattern BigInteger before comparison. When the constant representation is a decimal string like '-.99999', the code then called BigDecimal.equals(BigInteger), which always returns false, so missing_constant values were never recognized and the value was incorrectly compared against Field_Statistics min/max bounds. Fix: when the incoming Number is a BigDecimal and the constant representation is decimal, compare directly via BigDecimal.compareTo() before falling through to the IEEE 754 bit-pattern path. Also refactors the repr_decimal boolean into named intermediate variables (hasDecimalPoint, hasScientificNotation) for readability. Adds test case using pccds.xml/pccds.tab from the compil-comet dataset which exhibits the original failure. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
| // conversion that causes missing_constant values like "-.99999" to never match. | ||
| if (number instanceof BigDecimal && repr_decimal) { | ||
| BigDecimal constant = SpecialConstantBitPatternTransforms.asBigDecimal(constant_repr, radix); | ||
| return constant.compareTo((BigDecimal) number) == 0; |
There was a problem hiding this comment.
Big thumbs-up for compareTo 🎉
| boolean hasScientificNotation = (constant_repr.contains("E") || constant_repr.contains("e")) | ||
| && !constant_repr.startsWith("0x") && !constant_repr.startsWith("0X"); |
There was a problem hiding this comment.
Note that the hexadecimal exclusion here applies only to scientific notation, not to the decimal-point test. That means something like 0x1.23 is still classified as repr_decimal.
This is not a regression, as the behavior already existed before this pull request. Maybe something to note for the future.
nutjob4life
left a comment
nutjob4life
left a comment
There was a problem hiding this comment.
I'd go ahead and approve this as is (and the comments I interspersed in the code aren't deal-breakers), except the tests don't pass now:
[ERROR] Failures:
[ERROR] CucumberTest.Example #1.4: NASA-PDS/validate#1379-1 summary:totalWarnings ==> expected: <3> but was: <0>
[ERROR] CucumberTest.Example #1.65: NASA-PDS/validate#427-1 summary:totalWarnings ==> expected: <2> but was: <0>
[ERROR] CucumberTest.Example #1.8: NASA-PDS/validate#690-1 summary:totalWarnings ==> expected: <888> but was: <0>
[INFO]
[ERROR] Tests run: 327, Failures: 3, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
I ran them twice just to make sure, but got the same failures.
|
@nutjob4life in the future, if the tests don't pass, let's not approve. There are very rare cases (e.g. API out of sync) where PRs should be merged when tests are failing and those cases should be called out in the PR description describing why those tests are failing. |
|
@jordanpadams wrote:
Sounds good. (I did in fact not approve this one 😌) |
2 participants
🗒️ Summary
Fixes a bug where
missing_constant(and other special constants with decimal values) were not suppressingerror.table.field_value_out_of_min_max_rangeerrors in ASCII character/delimited/binary table fields.Root cause: In
SpecialConstantChecker.sameContent(), values arriving asBigDecimal(all ASCII numeric field types go throughNumberUtils.createBigDecimal()) were being convertedBigDecimal → Double → BigInteger(raw IEEE 754 bit pattern)before comparison. For a decimal constant like-.99999, the code then calledBigDecimal.equals(BigInteger), which is alwaysfalse, so the special constant was never recognized. The value then fell through to theField_Statisticsmin/max comparison and incorrectly triggered an error.Fix: Added an early-return path in
sameContent(): when the incomingNumberis aBigDecimaland the constant representation is decimal (contains.or scientific notatione/E), compare directly viaBigDecimal.compareTo()before the bit-pattern conversion path.Also refactors the
repr_decimalboolean into two named variables (hasDecimalPoint,hasScientificNotation) for readability per code review.⚙️ Test Data and/or Report
Added Cucumber scenario
1660-1using the real-worldpccds.xml/pccds.tabdataset from the compil-comet archive (linked in the issue). Before fix: 46error.table.field_value_out_of_min_max_rangeerrors. After fix: 0 errors, product passes.♻️ Related Issues
Fixes #1660
🤓 Reviewer Checklist