Concurrent loop/string processing to speed up Livecode

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5187
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Concurrent loop/string processing to speed up Livecode

Post by jacque » Thu Dec 05, 2019 6:47 pm

The example in the dictionary that follows the "as set" description is not an example of "as set" but rather a generic array example. If you split as set you'd get this:

Code: Select all

KEY              VALUE 
A apple       true
B bottle      true
C cradle      true
The original list becomes the keys and a default value of "true" is assigned to each element. This is a quick way to convert a list into the keys of an array without looping through each line and setting it up manually.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7179
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Concurrent loop/string processing to speed up Livecode

Post by FourthWorld » Thu Dec 05, 2019 8:34 pm

Thanks. Yes, the description was clear enough. It host seemed a curious choice to have a specific string as the default value. I'm assuming there was a reason for that choice; it might be useful to know what that reason was.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

bogs
Posts: 4111
Joined: Sat Feb 25, 2017 10:45 pm

Re: Concurrent loop/string processing to speed up Livecode

Post by bogs » Thu Dec 05, 2019 10:30 pm

FourthWorld wrote:
Thu Dec 05, 2019 5:09 pm
rkriesel wrote:
Thu Dec 05, 2019 6:17 am
<aside>How could the dictionary evolve to help more?</aside>
1.) the online version needs to be kept current with the last stable version.
2.) the Linux version of LC needs a working browser control so it becomes possible once again to consult the Dict offline.
3.) the formatting is FUBAR compared to the old version made entirely in LC
4.) Additionally, like much of the product experience, it would be very beneficial to the perceived value of LC to have a style guide for all UI elements, and ensure that all components of the IDE adhere to it.
5.) And lastly, having someone with skills and experience in UX contributing to the Dict would help. It's a fine work in terms of engineering, but a poor user experience. Having defaults that include everything under the sun turned on results in MANY searches yielding seemingly duplicate results, mish-mashing glossary and other elements with the actual Dict definitions needed for immediate scripting. This creates uncertainty for the user, who is unsure which of several similar or even identical entries to pick, creating at least lost time and at worst an adverse reaction the the product design. Some prudent judgment about use cases would clean that up, making it more efficient and enjoyable to use.
I completely echo the above.

It was so well said, Richard, that I actually have nothing of value to add to it :shock:
Image

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5187
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Concurrent loop/string processing to speed up Livecode

Post by jacque » Fri Dec 06, 2019 5:42 pm

FourthWorld wrote:
Thu Dec 05, 2019 8:34 pm
Thanks. Yes, the description was clear enough. It host seemed a curious choice to have a specific string as the default value. I'm assuming there was a reason for that choice; it might be useful to know what that reason was.
I'm guessing it was strictly arbitrary, you have to put *something* in there. It could just as easily be 1 or 0.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

rkriesel
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 73
Joined: Thu Apr 13, 2006 6:25 pm

Re: Concurrent loop/string processing to speed up Livecode

Post by rkriesel » Mon Dec 09, 2019 10:56 pm

jacque wrote:
Fri Dec 06, 2019 5:42 pm
FourthWorld wrote:
Thu Dec 05, 2019 8:34 pm
Thanks. Yes, the description was clear enough. It host seemed a curious choice to have a specific string as the default value. I'm assuming there was a reason for that choice; it might be useful to know what that reason was.
I'm guessing it was strictly arbitrary, you have to put *something* in there. It could just as easily be 1 or 0.
Since those who know haven't answered, I'm guessing "true" has the primary advantage of simplifying testing the existence of a key.
before: if tKey is among the keys of tArray
after: if tArray[tKey]

-- Dick

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5187
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Concurrent loop/string processing to speed up Livecode

Post by jacque » Tue Dec 10, 2019 5:50 pm

Since those who know haven't answered, I'm guessing "true" has the primary advantage of simplifying testing the existence of a key.
You may be right, that sounds like a very Waddingham thing to do.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2199
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Concurrent loop/string processing to speed up Livecode

Post by [-hh] » Tue Dec 10, 2019 7:59 pm

Yes, Dick hit the nail on the head.
Using true for arrays "as set" simplifies and fastens the check for being an element of "combined" (mathematical) sets tA and tB:
  • if tA[tKey] is true:
    tKey is element of tA
  • if tA[tKey] and not tB[tKey] is true:
    tKey is element of the difference tA \ tB
  • if tA[tKey] and tB[tKey] is true:
    tKey is element of the intersection of tA and tB
  • if tA[tKey] or tB[tKey] is true:
    tKey is element of the union of tA and tB
  • if tA[tKey] and not tB[tKey] or tB[tKey] and not tA[tKey] is true:
    tKey is element of the symmetric difference of tA and tB.
This may be, for large arrays, *much* faster than to build the (complement,) difference, intersection, union or symmetric difference of the arrays and then to check tKey against all keys (is among the keys).

For beginners who read this:
tA[tKey] in a set is either true or empty for any key tKey.
Because  empty is not true  we have:
tA[tKey] in a set is either true or not true for any key tKey.

[Edit: Dec 11, 2012]
p.s. One could be tempted to conclude "empty is false" from that as I did.
But LC returns empty is false as false. This is NOT a bug (due to string conversion):
Here the enlightening answer from Mark Waddingham.
This [empty is false = false] is definitely not a bug.

empty is the string ""
true is the string "true"
false is the string "false"

So empty is not true and empty is not false.

In the cases where the result of an expression is used as a condition, e.g. if <condition>, the engine does:

if <condition> is "true" then
...
end if

i.e. The only things considered to be 'true' are things which convert to the string "true".
shiftLock happens

Post Reply

Return to “Talking LiveCode”