Monte Goulding's day off? ;-) mergJSON - Documented Bug or Feature?
mark at livecode.com
Wed Jun 29 08:21:05 EDT 2016
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
> 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
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
> 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
> 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
> 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 "#.#######################################"
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:
(These are related to Excel, however they are linked to from the FoxPro
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).
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode