Stop Integer Coercion to Scientific Notation in JSON

panagiotis merakos merakosp at gmail.com
Wed Sep 11 09:50:13 EDT 2019


Hello all,

There is not a lost of precision in the operations. The problem is just
that LCB *displays* the value of large numbers in scientific notation, but
if you actually do any calculations with the variables that hold these
numbers, the calculations are accurate.

In other words the variables do hold the full value - it is the emission
which is turning them into the scientific notation.
(emisson as text in json)

Hope this helps.

Kind regards,
Panos
--

On Wed, 11 Sep 2019 at 16:29, Sannyasin Brahmanathaswami via use-livecode <
use-livecode at lists.runrev.com> wrote:

> One tries his best to not get excited by bugs that are left untouched,
> With some OS's to. keep current, engineering  has a tough time, we all know
> that … but this one pushes a button…
>
> bug https://quality.livecode.com/show_bug.cgi?id=18159
>
>
> How can such a bug go unfixed for three years? Computing should be "exact"
> when comes to simple "arithmetic"  operations, after all the CPU is nothing
> but passing bit and bytes around, in large equations. …. if "arithmetic"
> operations are off all Apps and any OS would immediately have a meltdown
>
> So to have a process that loses digits from a simple integer > 100,000 Is
> "unconscionable "
> …for a language of the 21century
>
> We need to know that we can depend on "seconds" through all
> processes…"time" is fundamental to computing at all levels.
>
> You should put this on the list a top priority.
>
> With so many apps now working with the cloud, REST/XML and related
> proprietary transfers using JSON.  It is ever more in important that we can
> depend of LiveCode for the simple act of keeping a number/integer (any
> size) intact!
>
> At least I think I have a hack: to store time as a string -- the internet
> time in the json to keep in intact and to convert it after unpacking, and
> before store again but  something as simple as
>
> put ( (the seconds) +3600) into tOneHourLater
>
> Should always work.
>
> God help anyone using Livecode widgets/LCB extensions for physics.
>
> BR
>
>
>
> Hello Brahmanathaswami,
>
> I think this is because of how currently some handlers in lcb work.
>
> See bug https://quality.livecode.com/show_bug.cgi?id=18159 (and the
> related bugs) for more details.
>
> This affects other areas, such as how large numbers are shown in the
> variables pane in the debugger.
>
> Kind regards,
> Panos
> --
>
> On Tue, 10 Sep 2019 at 22:59, Sannyasin Brahmanathaswami via use-livecode <
> use-livecode at lists.runrev.com<mailto:use-livecode at lists.runrev.com>>
> wrote:
> setPref "preferences/global/lastRunDate", (the seconds) # e.g 1568144731
>
> put getPref ("preferences/global/lastRunDate") into tLastRunDate
>
>         returns
>                         {"preferences":
>                                 {"global":
>                                         {"lastRunDate": 1.56814e+09},
> [snip]
>
> # we are using jsonImport
>
>                  put jsonImport(tJSON) into tPreferencesA
>
> # handle data and
>
>                 put jsonExport(tPreferencesA) into tJSON.
>
> # thereafter my simple arithmetic functions like
>
>                 put (tLastRunDate + 3600) into 1HourLater
>
> # now throw a "left operand" error....
>
> How can we prevent the coercion of simple integer notation to scientific?
>
> Why is it needed for simple 10 digit number is beyond me.
>
> There is nothing about automatic coercion in the dictionary.
>
> BR
>
>
>
>
>
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com<mailto: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
> _______________________________________________
> 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
>



More information about the use-livecode mailing list