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

[Mark Waddingham]

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?

The JSON format is quite clear that things that are not in quotes are 
text representations of a non-string value - thus they should be 
returned as that datatype.

 From JSON's point of view, there is a huge semantic difference between 
"1.4" and 1.4, just as there is a huge difference between "true" and 
true.

As JSON is an untyped format, preserving the type of the values you get 
back is very important as there is no other way to determine what the 
author of the JSON file intended - particularly if some fields are 
'variants' where the meaning of the field depends on the explicit type 
of the value.

> if I wanted the number to be 1.399999 thats what I would put in there.

The numbers you are getting are correct +/- a miniscule error due to the 
problem with representing base 10 fractions as base 2 fractions. This 
problem is solved by ensuring you 'round' appropriately to the number of 
significant figures you require before display.

If you aren't rounding your numbers before display appropriately 
(presumably by setting a numberFormat with *way* too many decimal 
places) then you will see all the gory details.

> I wrote a JSON library for Visual foxpro a couple of years ago and the 
> only
> change it made was if there was an integer of say 1 or 2 it would 
> change it
> to 1.0 or 2.0 because Foxpro itself reads any numbers from a file as 
> Real
> rather than integer but the actual value is still the same 1.0 is 1. I
> could have coded against that but it would have been a bit convoluted 
> and
> would have slowed the system down so I left it as is.

Well, 1.0 and 2.0 *are* representable exactly as binary floating point 
numbers - so i'd expect them to round-trip 1:1 from converted to a 
decimal representation (i.e. as a string). Looking at the docs of visual 
foxpro - it isn't entirely clear about what storage format it uses for 
Numeric types (although they sound like binary floating point). FoxPro 
does appear to have a 'Decimal' type - e.g. for Currency values and such 
- which is one thing LiveCode does not currently have. However, given 
that you say 1 got converted to 1.0 in your FoxPro library, that 
suggests you were using Numeric rather than Currency. The difference 
here is that it *sounds* like FoxPro is doing some default rounding for 
display that your scripts in LiveCode currently are not.

Indeed, if you do 'put 1.4+0' in the message box in LC, you will get 1.4 
- the default numberFormat formats numbers to 6 decimal places. If you 
set the numberFormat to show a large number of decimal places, however, 
you will see the error:

    set the numberFormat to "#.#######################################"
    put 1.4+0

Gives:

    1.399999999999999911182158029987476766109

By the way, its worth pointing out that FoxPro mentions that you need to 
'mind your rounding', as do the docs for XL. Indeed, here are some 
resources from Microsoft which might be of interest:

     https://support.microsoft.com/en-us/kb/214118
     https://support.microsoft.com/en-us/kb/78113

(These are related to Excel, however they are linked to from the FoxPro 
docs).

At the end of the day, if you want strings out of JSON, then you are 
probably best ensuring the JSON values are represented as strings in the 
JSON file - then you can convert them as you wish in LiveCode (although 
that won't make any difference to what you are seeing - as LiveCode 
numbers are IEEE754 64-bit floating point values). However, it sounds to 
me that this is more a case of not rounding your numbers for conversion 
to strings appropriately (i.e. not setting the numberFormat correctly).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps