LAVA JSON API

[PBD_ctrl]

This is my first post but I have been browsing LAVA for years!  I couldn't figure out how to post this within the repository forums so I decided to throw it up here.

 

I am using the JSON LabVIEW 1.1 API in a large project and just came across an issue.  The attached VI shows the problem but what it boils down to is that doubles get truncated to 6 decimal places.  It is being truncated because of the Format Into String function's "format string".  Was this done on purpose?  I know how to make the change that I am looking for but I would like to see it get worked into the package's source.

 

Thanks,

     -Pat 

 

 

Build Basic JSON.vi

[drjdpowell]

For lack of a better reason I just used the default.  More digits would be better for precision, but worse for compactness.  Perhaps we could make the format string an optional input?

[PBD_ctrl]

A format string would help but what about the set variant VI?

[drjdpowell]

The set variant VI would need the same input, either "numeric format" or "numeric precision".

[drjdpowell]

Googling other JSON implementations, I think we should change the format to the following:

 

SGL: %#.6g (equivalent to the %#g we have now)

DBL: %#.14g

EXT: as many digits as the LabVIEW functions to make text from numbers give us, which seems to be only %#.17g from my limited testing

 

This is deliberately less than maximum precision, so as not displaying decimal numbers like 0.1 as 0.10000000000000001.

[drjdpowell]

Mixed up precision and significant figures. Now proposing:

SGL: %#_7g (seven figures)

DBL: %#_15g

EXT: ?!? (I can't seem to get more significant figures for EXT than for DBL using the format as text functions).

Edited December 20, 2013 by drjdpowell

[drjdpowell]

Here's an updated JSON package.  Please give it a try.

lava_lib_json_api-1.1.2.19.vip

[PBD_ctrl]

Looks good to me!  Thanks for the change.  Are you considering getting this onto the LV Tools Network?

[mje]

If LabVIEW limits the string representation of EXT numbers you may be able to extract more digits by rounding to some precision, generating the first set of digits, then generating the second group based off the difference. Ugly for sure, but if that's the only way...