Exception when trying to handle missing_constant == Infinity

[jordanpadams]

Checked for duplicates

Yes - I've already checked

🐛 Describe the bug

When I tried validating a product with missing_constant == Infinity, I get a FATAL_ERROR.

Upon further investigation, it is throwing a java.lang.NumberFormatException

🕵️ Expected behavior

I expected validate to complete successfully.

📜 To Reproduce

$ validate-3.5.0-SNAPSHOT/bin/validate -t ~/Downloads/MDIS_RTM_N01_010599_7521824_1.xml

java.lang.NumberFormatException: For input string: "Infinity"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Integer.parseInt(Integer.java:668)
	at java.base/java.math.BigInteger.<init>(BigInteger.java:538)
	at gov.nasa.pds.tools.validate.content.SpecialConstantBitPatternTransforms.asBigInt(SpecialConstantBitPatternTransforms.java:25)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.sameContent(ArrayContentValidator.java:352)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.isSpecialConstant(ArrayContentValidator.java:372)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.validatePosition(ArrayContentValidator.java:295)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.process(ArrayContentValidator.java:161)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.process(ArrayContentValidator.java:152)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.process(ArrayContentValidator.java:152)
	at gov.nasa.pds.tools.validate.content.array.ArrayContentValidator.validate(ArrayContentValidator.java:126)
	at gov.nasa.pds.tools.validate.rule.pds4.ArrayValidator.validateDataObjectContents(ArrayValidator.java:104)
	at gov.nasa.pds.tools.validate.rule.pds4.ArrayValidator.validate(ArrayValidator.java:59)
	at gov.nasa.pds.tools.validate.rule.pds4.DataDefinitionAndContentValidationRule.validate(DataDefinitionAndContentValidationRule.java:127)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at gov.nasa.pds.tools.validate.rule.AbstractValidationRule.execute(AbstractValidationRule.java:64)
	at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191)
	at gov.nasa.pds.tools.validate.task.ValidationTask.execute(ValidationTask.java:130)
	at gov.nasa.pds.tools.validate.task.BlockingTaskManager.submit(BlockingTaskManager.java:26)
	at gov.nasa.pds.tools.label.LocationValidator.validate(LocationValidator.java:285)
	at gov.nasa.pds.validate.ValidateLauncher.doValidation(ValidateLauncher.java:1429)
	at gov.nasa.pds.validate.ValidateLauncher.processMain(ValidateLauncher.java:1715)

🖥 Environment Info

No response

📚 Version of Software Used

3.5.0-SNAPSHOT

🩺 Test Data / Additional context

Data product is very large, so to-be-sent via LFT.

🦄 Related requirements

No response

⚙️ Engineering Details

No response

[al-niessner]

@jordanpadams

The definition of these special constants (not to mean IEEE 754 special constants) are defined to be: Values of this attribute should be represented in the same data_type as the elements in the object with which the Special_Constants class is associated.

Super clear. Anyway, I do not think any special constant is meant to +/- inf or nan since those are data type dependent. Matching types is then pushed directly back onto the label writer. I think the right comparison is 0x7f800000 for positive inf single precision and 0x7ff0000000000000 for positive inf double. I have seen some of these patterns in previous tickets like the one that had us start handling 0x.

[jordanpadams]

@al-niessner so are you claiming that this data is actually invalid? And they should be using something like 0x7f800000 instead of "Infinity"?

[al-niessner]

@al-niessner so are you claiming that this data is actually invalid? And they should be using something like 0x7f800000 instead of "Infinity"?

@jordanpadams

Yes. Special constants do not have data types and it is the label writer responsibility to make sure the constant is of the correct data type. Infinity in single is not the same as double with more zeros (look closely at prior post). Therefore, infinity puts the type responsibility on the reader while 0x7... puts it on the writer.

The data can be +/-Inf or Nan or some limited form of those because they do have a data type associated with them and therefore may to a specific bit pattern:

validate/src/main/java/gov/nasa/pds/tools/validate/content/table/FieldValueValidator.java

Lines 56 to 57 in 3d84b0e

	private final List<String> INF_NAN_VALUES = Arrays.asList("INF", "-INF", "+INF", "INFINITY",
	"-INFINITY", "+INFINITY", "NAN", "-NAN", "+NAN");

[jordanpadams]

@al-niessner for this one, in the meantime, can we at least catch the NumberFormatException and throw an ERROR?

[al-niessner]

@jordanpadams

Some test data please.

[jordanpadams]

@al-niessner see LFT. I can resend if needed.

[al-niessner]

@jordanpadams

Data from LFT works. See PR #894 for details.