{"task": {"agent_timeout": 3000, "task": "testgen__fasterxml__jackson-core-1182", "verifier_timeout": 3000, "instruction": "The following text contains a user issue (in <issue/> brackets) posted at a repository. Further, you are provided with file contents of several files in the repository that contain relevant code (in <code> brackets). It may be necessary to use code from third party dependencies or files not contained in the attached documents however. Your task is to identify the issue and implement a test case that verifies a proposed solution to this issue. More details at the end of this text.\n<issue>\n      Currently `JsonParser` has method `getNumberType()`, with semantics that are loose for many textual formats.\nBasically formats like JSON do not have similar types as programming languages: so while we have separate `NumberType` entries representing `float` (32-bit binary FP), `double` (64-bit \"double\"precision binary FP) and `BigDecimal` (unlimited-precision, decimal FP), there is no efficient mechanism to actually produce correct `NumberType` for floating-point values.\nBecause of this, basically all FP values claim to be of `NumberType.DOUBLE` for such formats.\nThis can be problematic if values are converted first to `double`, then to `BigDecimal`, since former cannot accurately represent all decimal numbers.\n\nHowever, binary formats often have specific storage representations that can provide this type information.\n\nThe problem comes when converting to Java types: both `java.lang.Number` (or generally `java.lang.Object`) and `JsonNode`.\nIn this case we would ideally use either:\n\n1. Exact type if known (binary formats) OR\n2. Well-known type -- `Double` OR `BigDecimal`, based on configuration\n3. In some edge cases (not-a-number aka `NaN`), `Double` as that can represent such values.\n\n(further complicating things, we also have secondary means of producing `NaN` values: value overflow for `double` (and theoretically, but not practically, `float`) which can produce `+INFINITY`)\n\nGiven all above confusion, I think we need a new method like `getNumberTypeFP()` -- with matching `enum NumberTypeFP` (to be able to express value `UNKNOWN`, no need for integer types).\nThat will allow deserializers to know if \"true number type\", and base logic on that, specifically avoiding conversions in case of Binary formats and allowing their use for Textual formats (or in general formats without explicit type information for FP numbers).\n\n**EDIT**: originally thought we'd need `getNumberTypeExplicit()`, but since the need is specifically for floating-point numbers, let's call it `getNumberTypeFP()` instead; no need for non-FP types. And can indicate semantics are for strict/explicit type.\n\n</issue>\nPlease generate test cases that check whether an implemented solution resolves the issue of the user (at the top, within <issue/> brackets).\nYou may apply changes to several files.\nApply as much reasoning as you please and see necessary.\nMake sure to implement only test cases and don't try to fix the issue itself.\nYou are not allowed to read git history.\n", "memory": "8192m", "runnable": false, "difficulty": "hard", "language": "", "cpus": "", "instruction_truncated": false, "category": "test-generation", "compose": false, "has_solution": true, "oracle": null, "docker_image": "", "taskset": "devopsgym", "tags": ["test-generation", "devops-bench"]}, "runs": []}