Hello all,
A heads-up for anyone using the jsongetb() function, for turning a
JSON string into a gretl bundle.
Up till now, when jsongetb encountered a JSON array containing
numeric values it constructed an array of strings (using sprintf on
the numbers). This was not very nice, but seemed like the easiest
thing to do since we were matching each JSON array to a gretl array,
and gretl does not have an "array of scalars" type as such.
New in git (not yet snapshots) we're converting numeric JSON arrays
to gretl matrices -- vectors, to be precise, because although JSON
arrays can be nested, JSON doesn't have a two-dimensional array as
such.
In case it's of concern to anyone, let me be a little more explicit.
(1) JSON: { "x" : [1, 2, 3] }
Old jsongetb gave x as an array of strings ("1", "2", "3").
New jsongetb gives x as a column vector {1, 2, 3}'.
(2) JSON { "x" : [[1, 2, 3], [4, 5, 6]] }
Old jsongetb gave x as an array of arrays, each element of which was
an array of strings: ("1", "2", "3") and ("4",
"5", "6")
New jsongetb gives x as an array of matrices (column vectors),
namely {1, 2, 3}' and {4, 5, 6}'.
Clearly, this change will break hansl code expecting JSON numeric
arrays to come through in the old way. This applies to the dbnomics
addon and the (new, not really published) geoplot addon, but the
current code for those packages has been modified to handle both
cases. And we didn't find any current contributed function packages
that rely on the old jsongetb behaviour.
If anyone has "serious" code they're using that is broken by the
change in git, please tell us!
Further comment for experts: What about missing values? And JSON
arrays of mixed type (since that's allowed, god help us)?
We judge a JSON array to be numeric based on the type of its first
element. If subsequent elements have a null value, or a string value
of "." or "NA", they are taken to be gretl NAs. Otherwise mixed
types provoke an error in jsongetb.
Allin