LiveCode Forums.

Posted: **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.

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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

Posted: **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.

Posted: **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".

LiveCode Forums.

Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode

Re: Concurrent loop/string processing to speed up Livecode