Bug: JSON parser infers data type from input parameter value

[pelesh]

Description how to reproduce the bug

JSON parser infers parameter data type from its value. This among other things will cause that floating point parameter is interpreted as integer if it is entered without decimal point in the input file. Retrieving this parameter as a floating point type will then cause an exception to be throw:

terminate called after throwing an instance of 'std::bad_variant_access'
Abort trap: 6

Possible solutions are

• to interpret every parameter as the floating point number
• have separate enums for real, integer and boolean parameters.

@superwhiskers

GridKit™ version

develop @ b191e66

System and environment details

Observed on MacOS 15.6.1 with gcc 13.3.0 and clang 16.0.6.

Additional information

No response

[pelesh]

Actually, even adding decimal point at the end does not help. One needs to add at lease one decimal place:

• Setting Pmax: 1 in JSON gives integer.
• Setting Pmax: 1. is interpreted as integer, as well.
• Setting Pmax: 1.0 is interpreted as real parameter.

[pelesh]

CC @abirchfield @lukelowry

[superwhiskers]

i'd say this was more underspecified behavior if anything, not a bug.

if we really want implicit conversion to double we can change the parsing code to use the implicit conversion functionality of the json library when retrieving values expected to be reals. that would work. then we explicitly state in the format spec that 1 (or any other integer literal) is interpreted as a real if the expected type is a real.

an alternative solution would be to just specify in the format that you need to have the decimal place with a zero at minimum. that would also solve the problem of it being unspecified.

[pelesh]

an alternative solution would be to just specify in the format that you need to have the decimal place with a zero at minimum. that would also solve the problem of it being unspecified.

Per @abirchfield, this would be difficult to enforce and would cause a lot of bug reports down the road.

[abirchfield]

To me the simplest solution for now is to just assume every parameter is floating point. Then we can have parameter checks if we need to restrict some to integer values.

[superwhiskers]

we don't really need to do that. there's the implicit conversion flag i mentioned above that will automatically convert to floating point if you try to access a value that can be coerced to floating point. iirc the only thing you'd need to do is set a define or something

[pelesh]

we don't really need to do that. there's the implicit conversion flag i mentioned above that will automatically convert to floating point if you try to access a value that can be coerced to floating point. iirc the only thing you'd need to do is set a define or something

Let me try to implement such case in the unit test.

[lukelowry]

I encountered this issue when translating the Texas 2000 bus case and Hawaii 37 bus case. My observations thus far tells me that almost 100% of the numerical data is floating point. Exceptions to this are flags. I had to ensure the JSON output had floating decimal digits for the floating point fields to parse the file without errors.

Consider the above when resolving this issue!