Monte Goulding's day off? ; -) mergJSON - Documented Bug or Feature?

[Lagi Pittas]

Hi Mark,

Thanks for the replies. But your second response I don't understand and the
whole point of what I was getting at.

"I suppose there could be an option to choose a 'number of decimal places'
option passed to the library - however, you will then potentially lose
information in your numbers. Therefore, it is probably better to do the
rounding in script after loading the JSON file."


If  "reals" are returned as  strings anyway then if the real says 2.30 how
can I be losing any precision if 2.30 is what's in the file?. The option
though would be a good idea but in the calling routine to MergJSON.. If it
is left blank or false then it uses the current setting of number format
 or if there is a string then that will be the format it uses.

But without looking at the code of the MergJSON library - it is closed
source I presume?, I would presume these changes could be made in there. My
original testing read my CSV file and dynamically buildt the arrays and
then I used the JSON library to export the values.

If I look at the Arrays using the variable display in the debugger they are
all showing as 2 decimals so I would expect them to export in the same
format - or am I again missing something about the debugger?

If added  global variable xx in the debugger with value 1.3456 and that is
how it shows and ll 2 decimal place prices still show the same so LC
"knows" how I want to see them.

Regards Lagi

On 29 June 2016 at 13:39, Mark Waddingham <mark at livecode.com> wrote:

> On 2016-06-29 14:21, Mark Waddingham wrote:
>
>> On 2016-06-29 13:22, Lagi Pittas wrote:
>>
>>> Can someone please explain the logic that says that a textual
>>> representation of information (CSV, XML a text file even) is translated
>>> to
>>> a IEEE number for us to round as we see fit?
>>>
>>
> Apologies - you can ignore all that I wrote in my previous response - I
> had forgotten that mergJSON is an old-style external so can only return
> string values!
>
> The C library it uses returns values in bools, ints, doubles and strings
> (at the C level). However, to return this data to LC it has to format all
> of these as strings (this is a limitation of the old externals interface).
> Therefore, it renders numbers in a form where you will not lose any
> information - i.e. with 16 decimal places. This is the best way to ensure
> you can then round them to a precision of your choice - hence you see what
> you see.
>
> I suppose there could be an option to choose a 'number of decimal places'
> option passed to the library - however, you will then potentially lose
> information in your numbers. Therefore, it is probably better to do the
> rounding in script after loading the JSON file.
>
> An alternative is to look at the JSON LCB library - this returns values as
> actual numbers, booleans and strings to LiveCode - which means that the
> numbers (in particular) get converted to strings respecting the
> numberFormat property currently in effect.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>