64 bit LC

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

64 bit LC

Clarence Martin via use-livecode
Hi folks, am I correct to assume that a 64 bit build of livecode will
enable the engine to do more precise math?  I want to build a tool that
requires precise division  with really small decimals and multiplication of
large numbers I want to know the number of digits is can reliably count on
on both sides of 0, and get 100% accurate result every time.

Thank you for any clarification on this subject. I defer to your greater
wisdom.

I can't test LC linux on right now, and I don't have a mac ..or i would
test this myself. :)
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
Surprised that no one has replied to this so I'll just offer a bit of
advice.  Whilst on the surface your assumption is correct, 64bit will
allow more accuracy than 32 bit, what you need to be aware of is the
same gotchas still apply to 64 bit LC as 32 bit LC.  Try this in the
msg box:

put 283.67-150.00-133.67

you should get 0. Now try this in the msg box:

put 283.67-150.00-133.67=0

You will get 'false' when you know you wanted true;  whether in 32bit
or 64 bit LC (Python, JBScript and some other languages) in some cases
you don't get the answer you know is correct.

The answer can be found in the Dictionary entry for NumberFormat:

Note: Since LiveCode does not use decimal numbers for its internal
calculations (for reasons of speed), the decimal representation of a
number is sometimes slightly off the correct number. For example,
10^-1 is equal to 0.1, but is calculated (to eighteen decimal places)
as 0.100000000000000006. Because of this, setting the numberFormat to
specify many decimal places after the decimal point may produce
unexpected results in a statement that tests for an exact number. To
prevent this, either avoid setting the numberFormat to a value more
precise than you need, or use the abs function instead of the =
operator to test equality:

put abs(283.67-150.00-133.67)=0

but we still don't get the answer we are expecting.

NumberFormat is not the only LC property/command/function that is
effected by the use of 'decimal representation'; trunc is another that
comes to mind.  But as can be seen by my example ALL math within LC is
effected by the way LC treats decimal values.

If you do a search of this mailing list for 'decimal floating point'
you will find plenty of examples of people who have been caught out by
this 'computing gotcha' - again it is not just LC that suffers from
this.  For any and all 'precision' math within LC, be it 32 or 64 bit,
special attention will need to be made to account for these fringe
cases.

Good luck.

On Mon, Jul 16, 2018 at 4:44 AM, Tom Glod via use-livecode
<[hidden email]> wrote:

> Hi folks, am I correct to assume that a 64 bit build of livecode will
> enable the engine to do more precise math?  I want to build a tool that
> requires precise division  with really small decimals and multiplication of
> large numbers I want to know the number of digits is can reliably count on
> on both sides of 0, and get 100% accurate result every time.
>
> Thank you for any clarification on this subject. I defer to your greater
> wisdom.
>
> I can't test LC linux on right now, and I don't have a mac ..or i would
> test this myself. :)
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
I'm surprised there wasn't an answer before this as well. This subject
comes up every few years.

The engine bitness won't affect math results. The standard library used
for math will fail beyond the scope at both ends and you'll end up doing
the math yourself with strings if you need more accuracy.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
On 7/20/2018 9:20 PM, Mark Wieder via use-livecode wrote:
> I'm surprised there wasn't an answer before this as well. This subject
> comes up every few years.
>
> The engine bitness won't affect math results. The standard library
> used for math will fail beyond the scope at both ends and you'll end
> up doing the math yourself with strings if you need more accuracy.
>

There have been enhancement requests in the past (I think) for a more
precise math library that the IEEE or to add Binary Coded Decimal (BCD)
math to LC. I can't seem to find them in the Quality Center just now though.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Wouldn't it be great if we could forgo the speed in lieu of accuracy? I mean, how could you develop an accounting application you could trust with this caveat?

Bob S


> On Jul 20, 2018, at 17:17 , Kay C Lan via use-livecode <[hidden email]> wrote:
>
> Surprised that no one has replied to this so I'll just offer a bit of
> advice.  Whilst on the surface your assumption is correct, 64bit will
> allow more accuracy than 32 bit, what you need to be aware of is the
> same gotchas still apply to 64 bit LC as 32 bit LC.  Try this in the
> msg box:
>
> put 283.67-150.00-133.67
>
> you should get 0. Now try this in the msg box:
>
> put 283.67-150.00-133.67=0
>
> You will get 'false' when you know you wanted true;  whether in 32bit
> or 64 bit LC (Python, JBScript and some other languages) in some cases
> you don't get the answer you know is correct.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 7/20/2018 9:20 PM, Mark Wieder via use-livecode wrote:
> I'm surprised there wasn't an answer before this as well. This subject
> comes up every few years.
>
> The engine bitness won't affect math results. The standard library
> used for math will fail beyond the scope at both ends and you'll end
> up doing the math yourself with strings if you need more accuracy.
>
Found it. By the LC CTO himself.

https://quality.livecode.com/show_bug.cgi?id=9349


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 7/20/2018 9:20 PM, Mark Wieder via use-livecode wrote:
> I'm surprised there wasn't an answer before this as well. This subject
> comes up every few years.
>
> The engine bitness won't affect math results. The standard library
> used for math will fail beyond the scope at both ends and you'll end
> up doing the math yourself with strings if you need more accuracy.
>
And this one: https://quality.livecode.com/show_bug.cgi?id=12440


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Thanks Kay for your detailed answer and everyone who chimed in
afterwards..... will have to read it all a couple of times.... ..... i
definitely have to do some tests in this regard and see how many decimal
points i really need......., but I'm not surprised that the answer is not
straight forward ..... lol...... i wish i could explain the use case
better, but i have some way to go before i can explain it . seems like lots
of workarounds available, so i think the coast is clear.





On Fri, Jul 20, 2018 at 9:32 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Wouldn't it be great if we could forgo the speed in lieu of accuracy? I
> mean, how could you develop an accounting application you could trust with
> this caveat?
>
> Bob S
>
>
> > On Jul 20, 2018, at 17:17 , Kay C Lan via use-livecode <
> [hidden email]> wrote:
> >
> > Surprised that no one has replied to this so I'll just offer a bit of
> > advice.  Whilst on the surface your assumption is correct, 64bit will
> > allow more accuracy than 32 bit, what you need to be aware of is the
> > same gotchas still apply to 64 bit LC as 32 bit LC.  Try this in the
> > msg box:
> >
> > put 283.67-150.00-133.67
> >
> > you should get 0. Now try this in the msg box:
> >
> > put 283.67-150.00-133.67=0
> >
> > You will get 'false' when you know you wanted true;  whether in 32bit
> > or 64 bit LC (Python, JBScript and some other languages) in some cases
> > you don't get the answer you know is correct.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Just whip out your HP-35. It gets right answers!
.Jerry

> On Jul 20, 2018, at 6:32 PM, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Wouldn't it be great if we could forgo the speed in lieu of accuracy? I mean, how could you develop an accounting application you could trust with this caveat?
>
> Bob S
>
>
>> On Jul 20, 2018, at 17:17 , Kay C Lan via use-livecode <[hidden email]> wrote:
>>
>> Surprised that no one has replied to this so I'll just offer a bit of
>> advice.  Whilst on the surface your assumption is correct, 64bit will
>> allow more accuracy than 32 bit, what you need to be aware of is the
>> same gotchas still apply to 64 bit LC as 32 bit LC.  Try this in the
>> msg box:
>>
>> put 283.67-150.00-133.67
>>
>> you should get 0. Now try this in the msg box:
>>
>> put 283.67-150.00-133.67=0
>>
>> You will get 'false' when you know you wanted true;  whether in 32bit
>> or 64 bit LC (Python, JBScript and some other languages) in some cases
>> you don't get the answer you know is correct.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 07/20/2018 06:47 PM, Paul Dupuis via use-livecode wrote:

> And this one: https://quality.livecode.com/show_bug.cgi?id=12440

I'm not sure what a status of 'hibernated' means.
Probably waiting until after something freezes over.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 07/20/2018 06:45 PM, Paul Dupuis via use-livecode wrote:

> On 7/20/2018 9:20 PM, Mark Wieder via use-livecode wrote:
>> I'm surprised there wasn't an answer before this as well. This subject
>> comes up every few years.
>>
>> The engine bitness won't affect math results. The standard library
>> used for math will fail beyond the scope at both ends and you'll end
>> up doing the math yourself with strings if you need more accuracy.
>>
> Found it. By the LC CTO himself.
>
> https://quality.livecode.com/show_bug.cgi?id=9349

Ah... from seven years ago.
Not that Rev 4.6.0-dp2 really brings back any memories.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On Jul 20, 2018, at 7:39 PM, Jerry Jensen via wrote:
>
> Just whip out your HP-35. It gets right answers!
> .Jerry

Long ago I sat on a bus at a conference next to the product manager for the HP-35. He said that they ran out of a part that was no longer made and had to re-design the board to use new modern components. The new processor was of course faster and so when it did it’s calculations it just instantly gave you the answer. The people that bought the new version, which looked just like the old version, didn’t trust it because it didn’t spend the time that it needed to do the calculations. Obviously there was something wrong.

It was such a big support problem that they had to re-design it and have it mimic the old version where it sits there and looks like it’s thinking for a while before it gave you the answer.

They swapped all of the brand new fast ones for the new slow ones and everyone was happy.

Mine is many many decades old and about a decade ago it stopped working so I called the support number just to see if anyone would answer and sure enough there was someone who answered that phone number. The number was probably four decades old and they figured out what my problem was. That’s a pretty successful product.

Kee Nethery

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 64 bit LC

Clarence Martin via use-livecode
HP was designing these things before there was math.
Sad what has happened to the company. I'd like to blame Fiorina for the
mess but she only took a bad thing and made it worse.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode