Inserting text into scrolling field

[westerw]

I have a scrolling field with these lines:
camel
carrot
cherry
cherub
concrete
cyan

How can I insert "candle" into the scrolling field in alphabetic order?
End result desired:
camel
candle
carrot
cherry
cherub
concrete
cyan

Also, how do I insert "cabbie" at the beginning of the scrolling field?
End result desired:
cabbie
camel
candle
carrot
cherry
cherub
concrete
cyan



thank you
bill

[bn]

Hi Bill,

you could do it like this

Code: Select all

put field "myScrollingField" into tData
put return &  "candle" after tData
sort tData ascending
put tData into field "myScrollingField"

the same for "cabbie"

Code: Select all

put field "myScrollingField" into tData
put return &  "cabbie" after tData
sort tData ascending
put tData into field "myScrollingField"

Kind regards
Bernd

[Newbie4]

If you know the line number, just use:

put "newWord" before line# of field "scrollingField"

if your scrolling field is already sorted, you can use the following code with your example:

put 0 into ctr
repeat for each line x in field "scrollingField"
add 1 to ctr
if x > "candle" then
exit repeat
end if
end repeat
put "candle" & return before line ctr in field "scrollingField"

This also works for "cabbie" in your example

[westerw]

Newbie4

Thanks. The "for each" repeat loop does it.
I was able to insert a new value into the list
and then save it in the custom property.

bill

[jacque]

I think it will fail with "zebra" though. The sort method is more reliable.

[Mark]

Bill,

I'd use Bernd's approach. Easy, quick and never fails.

Best,

Mark

[Newbie4]

Just add a check for the end of the list and this too will work every time

e.g.

if ctr = number of lines in field "scrollingField" then
put theWord & return after field "scrollingField"
else
put theWord & return before line ctr in field "scrollingField"
end if

It does not make sense having to re-sort a list every time. That is why you sort it the first time.

I know it does not matter much in this example but for really long lists, it does. If you work in other languages like Java, etc, you spend a lot of time learning different sort methods and then how to maintain that sort order (e.g. insert/delete new items into that array/list) without having to re-sort every time.

[Mark]

Hi,

This is not Java. This is LiveCode. The sort function is quite quick. Have you tested if the repeat-for-each approach is faster than the sort appraoch? For now I'd stick with the sort approach, entering all data and sorting when done.

Kind regards,

Mark

[dunbarx]

Newbie4

So your idea is to maintain the list, and find the line after which the new entry belongs, and insert it. Your use of the ">" operator here is sound as far as it goes, in that with strings, the operator does a char by char comparison in terms of ASCII values.

But I fully agree that sorting is more robust. Think of a list where there is more than one instance of a word. With your method, that new word would be inserted in the interior of that grouping, since it would be placed into the line right after the first instance of that word. The other duplicate words would follow that new entry.

There are many roads to solving a problem, and the level of robustness is sometimes elusive, and can only be determined by testing. You would be balancing, delicately, the existing sort order, and trying to modify it carefully without disturbing its essential character.

Dicey, as you see.

Craig Newman

[Newbie4]

Good points, good posts... good discussions.

I was assuming that there would be no duplicates because you do not usually have duplicates in a scrolling picklist.

You are also depending too much on the language and taking the easy way out by letting LiveCode do the sort, over and over again. You do not know which sorting method LiveCode uses to sort your list. It could be a very slow one for your data. There are many different sorting methods to use and some are targeted to specific types of data. To get the most efficiency and speed out of your code, you have to do it yourself. You know your data

There are many posts on this forum discussing speed advantages of code so this would be relevant to some cases.

We are getting into shades of grey. There are many different approaches and the circumstances often determine the preferable way for any of them. I just was meaning to point out there is no one "best" way. There are always tradeoffs to any way (speed, simplicity of code, fewer statements, less work, understandability, etc)

And as Craig pointed out, it is not easy to say one way is best at the beginning. As you get into the data, you find that you need code to handle the exceptions. I enjoy the challenge of doing it myself, finding the best way and coding around the exceptions that you may run into. Some people just want to get it working the easiest way and move on. To each his own.

That is what is good about these forums. We get a number of approaches and opinions.

[Mark]

Hi,

The big advantage of LiveCode is that in most cases you don't need to think about this kind of issues

Best,

Mark

[jacque]

One of the most valuable things I've ever taken away from any LiveCode conference is the suggestion that we "let the engine do the work". I've found it proves itself over and over again. There is almost no scripted code you can write that will be faster than the C code the engine uses. Scripted handlers always have some overhead the engine doesn't.

That said, for very long lists, doing it yourself might possibly be quicker. So I did some benchmarks. Here is the scripted sort as written in this thread:

Code: Select all

on mouseUp
  repeat 10000
    put any line of the colornames &cr after tList
  end repeat
  sort lines of tList
  put the milliseconds into tStart
  put tList into fld "scrollingField"
  scriptSort 
  put the milliseconds - tStart
end mouseUp


on scriptSort
  put 0 into ctr
  put "candle" into theWord
  repeat for each line x in field "scrollingField"
    add 1 to ctr
    if ctr = number of lines in field "scrollingField" then
      put theWord & return after field "scrollingField"
    else
      put theWord & return before line ctr in field "scrollingField"
    end if
  end repeat
end scriptSort

Getting or retrieving text from a field is one of the slowest things you can do in LiveCode. This takes 85728 milliseconds to complete, over a minute.

Let's change it so that it doesn't access the field more than once, and does all the work in a variable instead. This should dramatically improve performance:

Code: Select all

on mouseUp
  repeat 10000
    put any line of the colornames &cr after tList
  end repeat
  sort lines of tList
  put the milliseconds into tStart
  put tList into fld "scrollingField"
  scriptSort 
  put the milliseconds - tStart
end mouseUp


on scriptSort
  put 0 into ctr
  put fld "scrollingField" into tList
  repeat for each line x in tList
    add 1 to ctr
    if ctr = number of lines in tList then
      put theWord & return after tList
    else
      put theWord & return before line ctr of tList
    end if
  end repeat
  put tList into fld "scrollingField"
end scriptSort

This takes 2560 milliseconds on my machine.

Now let the engine do it:

Code: Select all

on mouseUp
  repeat 10000
    put any line of the colornames &cr after tList
  end repeat
  put the milliseconds into tStart
  sort tList
  put tList into fld "scrollingField"
  put the milliseconds - tStart
end mouseUp

That takes 5 milliseconds here.

[Newbie4]

A couple of points regarding your test example:
1. The code you are testing is not quite the same. You never test for the correct location of the word and the If statement should be outside the repeat loop.
2. On the average, the test code should test only 1/2 the number of items in the list (50% of words added will be before the middle and 50% after). Whereas the LiveCode "sort" has to go through the entire list every time to sort it. So for a 4,000 word list, on the average, the code method will do 2,000 comparisons, then insert the new word. Adding and re-sorting will always do 4,000 comparisons to ensure the list is completely sorted.

3. A sort designed for more random numbers (like I assume the LiveCode sort is) will be much slower for already sorted lists. That is why there are so many different kinds of sorts. Some are better for random lists others are better for partially sorted lists, etc. You use the sort appropriate for your data. Using the wrong sort will extract a time penalty.

4. This is all a moot discussion because if the data is already sorted, you should use a binary search which is extremely fast. For a 4,000 item list, a binary search will only need to do at most 12 comparisons, then insert it. By contrast, by adding the word to the end and sorting it will take at least 4,000+1 comparisons to sort the whole list again (maybe more depending on which sort method is used and how many passes it has to make through the data). The code for that is more complex but the time difference is substantial.

You are correct by saying, let the engine do the work but if you use the engine the wrong way, you waste a lot of time and clock cycles.

Thanks for the post

[dunbarx]

LC took 6.5 seconds to sort a 1,000,000 line list of six-char random words.

Interestingly, it only took 4.5 seconds to sort that already sorted list. Is this fodder for another thread?

Newbie, why not write your binary search on a similar unsorted list, and see how long it takes to insert a word way down. I used char from a-f, so it might be fair to insert "fdaaaa" or somesuch.

Craig

[jacque]

Newbie4, if you write some tests and post your results I'd be very interested. I'm always looking for better ways to do things.