JDP Science Tools

cancel
Showing results for 
Search instead for 
Did you mean: 

JSONtext Issue #95: displaying Floats always with a decimal ("0.0", "2.0", etc.)

It has been requested to make JSONtext always include a decimal when converting LabVIEW Floating-Point numbers to JSON form, even if the value is an integer.

 

Example: 0 --> 0.0

 

Q: is this a good idea?

Message 1 of 8
(2,409 Views)

Could this become a breaking change for someone? I'd recommend it's a setting one can optionally turn on and is off by default, akin to the PrettyPrint Boolean. Especially as this request seems limited to one user's scenario. Do you personally believe it has benefits James? Attempting to guess the datatype seems a little risky, what's the current problem if a variant float is imported as an integer? At type conversion it should be ok, right?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 2 of 8
(2,384 Views)

@Thoric wrote:

Could this become a breaking change for someone? I'd recommend it's a setting one can optionally turn on and is off by default, akin to the PrettyPrint Boolean. Especially as this request seems limited to one user's scenario. Do you personally believe it has benefits James? Attempting to guess the datatype seems a little risky, what's the current problem if a variant float is imported as an integer? At type conversion it should be ok, right?


The benefit I see is in Config files, where the User can tell if some parameter can be set to a fractional value.  Example: "Offset"=0.0

 

I am not at all interested in the computer "guessing the datatype", and think converting JSON to LabVIEW type without knowing the type (ie. converting to a Variant) is a design mistake.  Keep things as JSON until you are at the step where you know the type.   However, some people do want to use JSONtext as the JSON-serializer in a Variant-based config systems that support multiple serialization formats, and I'm not sure I should get in their way.  Though you are right, integer versus float should sort itself out at the Variant-to-Data step.

 

I would rather not have more optional functionality, and would want to make this the default if I included it.

0 Kudos
Message 3 of 8
(2,368 Views)

Personally I don't need it, and therefore don't want it, but I can appreciate the use case you've described and, so long as it doesn't break my existing code when I upgrade JSONtext versions, I'm ok with it.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 4 of 8
(2,359 Views)

The proposed change would not be a breaking change. It is part of the JSON specification that a numeric type:

  • MUST be stripped of leading zeros
  • CAN be stripped of zeros in the decimal part of the numeric

 

The only time when type conversion is not supported by LabVIEW is when you are presented with an array of mixed integers and floats. If all elements are not implicitly floats or integers, the resulting array will be malformed. It is possible to add a verification in the "Array of Variant Data" to "Variant Array of Data" conversion to ensure that this does not happen, but it seems like this (CPU intensive) computation could be avoided by simply exercising the "CAN be stripped" in a different way.

 

For clarity: 

[1, 1.1, 1.2, 1.3] will fail the cast to variant array if one does not ensure that all the elements are of the same type, whereas [1.0, 1.1, 1.2, 1.3] will not fail.

 

Behavior is also unpredictable: 

  • [1, 1.1, 1.2, 1.3] will succeed to cast to integers ==> [1, 1072798105, -1717986918, 1072902963]
  • [0.9, 1, 1.1, 1.2] will fail (error 74) if I32 and DBL are used for conversion
  • [0.9, 1, 1.1, 1.2] will succeed to cast to integers ==> [0.9, 4.94E-324, 1.1, 1.2] if I64 and DBL are used

If there is a clear way to infer integer vs float, the only thing to worry about is loss of resolution (floats) or wrapping (integers), but at least the result can be much closer to reality.

 

 

 

GCentral ChampionCLA
0 Kudos
Message 5 of 8
(2,348 Views)

Hi Norman, what are you talking about here?  You had me worried so I did all your examples with JSONtext and there was no problem.  [0.9, 1, 1.1, 1.2], for example, became 0,1,1,1 as I32 and 0.9,1.0,1.1,1.2 as DBL.

 

I then tried the "Variant to Data " function with Variant Arrays of mixed type (integers and floats) and it converted no problem also.

0 Kudos
Message 6 of 8
(2,338 Views)

Reading some more, I think you must be using OpenG-style flattening/unflattening techniques to convert and Array of Variants to a Variant containing and Array of Data.  But you could skip that step and let "Variant to Data" node convert the Array of Variants directly to your final Array of Data (not in Variant).  This will not have an issue with type, and will also be a lot faster.

0 Kudos
Message 7 of 8
(2,334 Views)

I found another use case that would benefit from the floating notation to be explicit.

 

I'm publishing data to IoT AWS Core (JSON payloads sent over MQTT) and when I apply a rule to route particular topics to a timestream database, the database creates the field type based on the value of the first payload it receives. As an example, if I publish "voltage" and its initial value is "0", it will be inferred as BigInt instead of Float. All subsequent values that contain a floating digit will be discarded as mismatched (they won't round to the nearest integer).

 

There are ways around... I can make sure to initialize the field with "epsilon" on the first call, but apart from the configuration file use case you mentioned, this is another way where the explicit trailing zero would be useful and improve interoperability.

GCentral ChampionCLA
Message 8 of 8
(1,991 Views)