Re: Troubles with inequality

2015-02-07 Thread Graham Samuel
Thanks - I don’t completely understand this as an economical solution, but I think what you’re saying is that any number, even stored in a variable, can be treated as a string - then things can be compared character by character. This is almost the solution I adopted, but I used fields since

Re: Troubles with inequality

2015-02-06 Thread Kay C Lan
On Thu, Feb 5, 2015 at 7:02 AM, Graham Samuel livf...@mac.com wrote: Thanks Jacque, a gold mine of information as usual. But it’s pretty obscure, isn’t it? All this started for me because I wanted to test if two numbers were equal, knowing that they probably weren’t exactly equal to the last

Re: Troubles with inequality

2015-02-05 Thread Jim Lambert
Graham wrote: I wanted to test if two numbers were equal, knowing that they probably weren’t exactly equal to the last decimal place but nevertheless were 'engineering equal' as it were - say to six places of decimals. Perhaps performing a statround() on the numbers prior to checking

Re: Troubles with inequality

2015-02-05 Thread Bob Sneidar
So here’s what I came up with. Pretty simple. on mouseUp put 5.226 into myVar set the numberFormat to 0.00 add .001 to myVar put myvar cr into myString set the numberFormat to 0.000 put myvar after myString put myString end mouseUp I get 5.23 5.227 Clearly the value in

Re: Troubles with inequality

2015-02-05 Thread Peter Haworth
It's almost like there should be a cast() function to change the type of a variable, although that would be most unLivecodeLike. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Wed,

Re: Troubles with inequality

2015-02-04 Thread dunbarx
1 of aa = word 1 of temp answer word 1 of aa end mouseUp -Original Message- From: Colin Holgate co...@verizon.net To: How to use LiveCode use-livecode@lists.runrev.com Sent: Wed, Feb 4, 2015 10:16 am Subject: Re: Troubles with inequality The numberformat only affect the appearance

Re: Troubles with inequality

2015-02-04 Thread Colin Holgate
Round has a problem in that rounding could change the nature of something. For example, you want to see if 1.9995 is similar to 1.9994, but you end up checking 1.9 against 2.0. One nice addition would be to give Trunk the same second parameter that Round has. Then you would keep the nature of

Re: Troubles with inequality

2015-02-04 Thread dunbarx
Colin. That would be a great feature. But trunc() takes no second param. I will ask for one, though. Craig -Original Message- From: Colin Holgate co...@verizon.net To: How to use LiveCode use-livecode@lists.runrev.com Sent: Wed, Feb 4, 2015 11:56 am Subject: Re: Troubles

Re: Troubles with inequality

2015-02-04 Thread Graham Samuel
Fascinating! Up to this moment, it seemed to me that the **appearance** of a number in a variable or more particularly in a field, **is** the number - where is the space where the engine can put an extended value? Is there something hidden in the object, perhaps in word 2? I mean, I have always

Re: Troubles with inequality

2015-02-04 Thread William Prothero
Colin: But: I don’t see this. Say your target accuracy is six figures. You would us: put round(myNum1,6) into num1 put round(myNum2,6) into num2 So, for example, 3.1234569 would round to 3.123457 3.1234563 would round to 3.123456, which would be unequal, but 3.1234567 would round up to 3.123457

Re: Troubles with inequality

2015-02-04 Thread Colin Holgate
Yes, my example wasn’t good. Interestingly, round(1.49) returns 1 and round (1.49) returns 2. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your

Re: Troubles with inequality

2015-02-04 Thread J. Landman Gay
On 2/4/2015 3:01 PM, Graham Samuel wrote: Fascinating! Up to this moment, it seemed to me that the **appearance** of a number in a variable or more particularly in a field, **is** the number - where is the space where the engine can put an extended value? The number retains its full value as

Re: Troubles with inequality

2015-02-04 Thread J. Landman Gay
It's obscure, yes, though the dictionary has this: Important! Changing the numberFormat does not automatically change the format of a number that's already in a container. It affects numbers only when they are calculated and then displayed or used as strings. Otherwise, the number retains its

Re: Troubles with inequality

2015-02-04 Thread Graham Samuel
Thanks Jacque, a gold mine of information as usual. But it’s pretty obscure, isn’t it? All this started for me because I wanted to test if two numbers were equal, knowing that they probably weren’t exactly equal to the last decimal place but nevertheless were ‘engineering equal’ as it were -

Re: Troubles with inequality

2015-02-04 Thread J. Landman Gay
On 2/4/2015 3:01 PM, Graham Samuel wrote: So really, if I want an uncomplicated string of characters derived from a number via setting the numberFormat and then doing a calculation, how do I get it? You can turn it into a string by putting empty after it: put 1.5 into tVar -- number

Troubles with inequality

2015-02-04 Thread Graham Samuel
Using LC 7.0.2-rc-2, I have two numbers, each in its own variable ('temp' and 'aa' below) that may differ at say the eleventh decimal place but are otherwise identical. This bit of code: set the numberformat to 0.## -- to get 6 dec place precision just for the comparison put temp*1

Re: Troubles with inequality

2015-02-04 Thread Colin Holgate
The numberformat only affect the appearance of the number, not its value. If you want to compare them based on the appearance characters, you can compare them as strings instead of numbers. Try this: on mouseUp put 1.234567 into temp put 1.2345678 into aa set the numberFormat to 0.###