Concurrent loop/string processing to speed up Livecode

[jacque]

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.

[FourthWorld]

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.

[bogs]

<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

[jacque]

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.

[rkriesel]

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]

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.

[[-hh]]

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".