This blog is about learning LiveCode to create interactive software for education. The main focus is on creating educational games, simulations, and microworlds. However, discussion of other software designs is not off limits. The focus is squarely on me learning LiveCode and sharing what I've learned, but if others learn something too, then all the better. I also hope those with more skill than I will share their expertise with me.
The second annual Digital Learning Conference was held Friday and Saturday here in Athens at the University of Georgia. I did my best to have LiveCode well represented. It was a wonderful conference, thanks to all the organizers and volunteers, especially my colleagues Dr. Christa Deissler and Dr. Theodore (TJ) Kopcha. There were some amazing, high quality sessions, such as those by innovative folks like Cat Flippen and Gary Shattuck. Very impressive stuff.
I did a LiveCode workshop and also presented my video analysis tool project. Not too many people attended my workshop, but several people asked me about it during the conference. I also used this opportunity to create another LiveCode "first project" (i.e. a fun first project designed especially for people who have never programmed before). I called it "Travel the USA!" and I think it worked well.
The conference had a participatory theme. Presenters were encouraged to propose sessions that emphasized interaction and hands-on activities. This motivated me to create a beta tester web site for people interested in trying out my video analysis tool. I barely pulled off the development of this web site in time for my session, but it all worked well. I designed my one-hour session as a mini-workshop about my video analysis tool. And, I now have a way to easily give people access to the tool while also gathering some important usability data from people with real interest in doing video analysis. I used a delightful video called "A Toy Train in Space" to demonstrate my video analysis tool - check it out:
As always, I enjoy introducing people who have never programmed before to LiveCode and what you can do with it.
I would like to say that this will be my most exciting, riveting, thrilling, hold-on-to-your-seat blog post yet. But, truth be told -- especially to the casual reader with little or no experience with LiveCode -- it may be the most boring one I've written. Of course, if you are a math nerd, perhaps the title piqued your interest a little with the mention of "order of magnitude." And I promise I will use this concept as the cornerstone of this posting. But, if that is the only thing that interests you, feel free to skip to the very end for a wonderful video about the powers of ten to make your decision to click your mouse or tap your screen to come here worthwhile.
Still here? OK, some quick background... In my previous post I mentioned how I received some helpful advice from Richard Gaskin a few months back suggesting that I could improve the performance of one of my projects if I were to take a different programming approach. Let me make it very clear at the start how grateful I am to Richard for taking the time to make this comment. This was a very kind gesture on his part. He was obviously under no obligation to respond, but took significant time to read through what I was working on and posted a very thoughtful comment. And, as I have googled other LiveCode questions and problems over the past two years, it's quite remarkable how many times I find an answer or suggestion given by Richard. He is a exemplary LiveCode citizen who is very willing to share his extensive expertise and who also seems to be constantly scanning the LiveCode world to try to help people out. I had the good fortune to meet him at RunRevLive 2014 in San Diego and he also seemed like a regular guy who was sincerely interested in whatever you were working on.
To briefly recap, I had been using text fields to handle list or data processing tasks and Richard wrote to say that I could dramatically speed things up if I would use variables instead. Here again is what Richard's wrote:
"...by using the "repeat for each" loop method combined with moving data out of the complex field structures into variables for use within the loop, this should bring your processing time down by at least an order of magnitude."
So yes, I've been thinking about this "order of magnitude" thing. I know Richard knows exactly what an "order of magnitude" means. In contrast, many people who throw this phrase around just kind of vaguely know it means "much more." I think a lot of other people think it means "twice as much." But, actually, an order of magnitude is used to compare things on a logarithmic scale, which most commonly uses base 10. The best example I can think is the Richter Scale, which is used to compare the size of earthquakes. An order of magnitude is a step along the scale that uses the powers of 10. For example, consider the difference between 10^2, 10^3, and 10^4. (I can't easily show exponents in this blog, so I'm using the character ^ to mean "raised to the power of.") If written out, these numbers are 100, 1000, and 10000, respectively. The difference between these three values is not equal, but instead increases exponentially. In fact, I think the best way to think of something measured on a logarithmic scale is to go in descending order, that is, from 10000 to 1000 to 10. At each step, you are going 90% the remaining distance! If you take a really huge number, such as 10^100 (known as a googol, by the way), you eliminate 90% when you go to 10^99. Going to 10^98 likewise removes 90% of that remaining amount, and so on.
So, for Richard to make the assertion that changing my programming approach would improve performance by at least an order of magnitude is really saying something - he's saying that the speed will increase tenfold. But the more I thought about it, I really wondered if this were true. So, I decided to test this hypothesis.
A LiveCode Programming Experiment
To test Richard's hypothesis, I quickly built a LiveCode app that performed a very simple operation: It takes a long list of words and transfers it from one "container" to another. In one version, the container is a text field. In a second version, the container is a variable. The idea is to see how long it takes for LiveCode to complete the process using both types of containers: 1) from one text field to the other text field; and 2) from one variable to the other variable.
And while that sounds simple enough, there are actually several other decisions we have to make. For example, should I take a word from the top of the first list and add it to the top of the second? Or, how about taking a word from the bottom of the first list and moving to the bottom of the second? And, there are quite a few more variations I could throw in. Let's start with what I think would be the most grueling for LiveCode to perform: taking a word from the top of the first list and moving it to the top of the second (thus deleting it from the first list). I'll call this experiment 1.
I titled the two fields "field1" and "field2," with the words being transferred from the first to the second. This loop repeats for as many words (one word per line in the field) as there are in the field. I always take the first word (on line 1) from field1, so you will see "line 1" listed twice above: first to "put" the word into field2, then to delete the word.
The following line above puts that word into the first line of field2:
putline1offield"field1"&returnbeforefield"field2"
As you can see, I also take advantage of the "before" keyword. This keyword very conveniently lets you put something at the beginning of a list of items without having to worry about how to move every other item. (A similar keyword is "after," which I talk about below.) It's also important to concatenate a "return" so that the word solely occupies the first line in field2.
The reason why I call this the most "grueling" approach for LiveCode to accomplish is that the words shown in the two fields are constantly shiftly, as shown in the video below.
The final two lines (before the "end repeat") are used to show a running tally of the number of words in each field as the loop executes. Depending on the experiment being performed, this can be the only feedback given to us that something is actually "working." So, I hope you can see that there is not many lines of code here.
Now, let's take a look at the related code for moving the words from one variable to another.
Your first reaction should be "Whoa, isn't this the same code?" Well, it's almost the same. Instead of referring to the two fields, I simply substituted the local variables "varField1" and "varField2". The important point is that this code processes the words exactly the same between the two examples, except for what containers are used to store the words.
If you are still confused as to what is going on here, watch a short movie I made demonstrating the app:
OK, let's take a look at the results of this first experiment.
Experiment 1 Results
Here are the results from the first experiment (time given in seconds):
Fields
Variables
move before and delete
141.72
54.59
As these data show, using variables instead of fields for this task is 2.6 times faster when the words are moved to the top of the second field the AND the words from the first field are deleted as they are moved. Yes, that is a big difference, but it is not an order of magnitude difference (i.e. 10 times faster). So, a preliminary conclusion is that Richard is correct in saying that the use of variables will be processed faster, but he overestimated the magnitude.
Experiment 2 Results
OK, let's do another experiment. What if we move the words from the first container to the second, but not delete them from the first. Accomplishing this difference is simply a matter of not including line 4 that begins with the word "delete." This does not seem to me to require as much processing power because you are doing less with the first field. But, who knows, perhaps some other dynamic is in play here that I'm not aware of. It's definitely worth exploring. Here are the results:
Fields
Variables
move before
73.59
27.30
In this case, using variables instead of fields for this task is 2.7 times faster when the words are moved to the top of the second field, but not deleted from the first field. This is a tad faster, but I'll call it a tie. I am a little surprised that the difference is not lower.
Two More Experiments: 1) Move After and Delete; and 2) Move After, But Don't Delete
I performed two other experiments where I used the keyword "after" instead of "before." As the word implies, this means that each word was added to the second field at the end of the field instead of at the beginning. From a processing standpoint, after the words fill the field in the second field you don't actually see the words being added to the field as they are "below" the bottom edge of the field. So, this would imply that LiveCode can process this more quickly than putting them before. I'll share the data in a moment, but there were no big surprises here. But, I did yet another experiment which did surprise me.
One Last Experiment: What Happens When You Hide the Fields
Watching the program execute this list processing task in all of the previous experiments, particularly when the words are moved to the top of the second field and deleted from the first, it seems clear that moving the words from field to field takes quite a bit of processing power. You can just see the difference. (Actually, I find it quite mesmerizing.) I wondered, though, what would happen if the fields were hidden from view? So, one more experiment was in order.
This last experiment was pretty simple. It's the same as the first experiment, but with both fields hidden. The data from this second experiment were very surprising. There was virtually no difference in processing time between using fields and using variables!
Here is a table with all of the data from all of the experiments:
Fields
Fields
Variables
Visible
Hidden
move before
73.59
27.29
27.30
move before and delete
141.72
54.60
54.59
move after
27.94
27.30
27.29
move after and delete
100.78
54.59
54.57
So, In Conclusion...
My main conclusion is that it doesn't seem to matter if you use fields or variables as the containers for list processing tasks such as the one used here, given the very important condition that the fields are not visible.
But on the Other Hand...
Of course, I might have completely misunderstood Richard's advice and therefore set up a perfectly useless experiment. That's OK, I've wasted time in much more uninteresting ways. But, I am open to any feedback that Richard or any other LiveCode expert may want to give me here. I'm even willing to revise my programming experiment to test other approaches, assuming I can figure out how to code it. Or, better yet, you could download the file yourself and revise it to test your own hypotheses - be sure to let me know what you find.
Many thanks again to Richard Haskin for making me think and for motivating me to explore this programming question. This is exactly the kind of feedback I was hoping for from experts in the LiveCode community when I began writing this blog.
Powers of 10 Video
I end this blog posting (most of which I'm sure many of you wisely skipped) by sharing what might be one of my most favorite science videos of all time. It's called simply "Powers of 10," and it is narrated Phillip Morrison, a famous physicist and science educator who taught at MIT and worked on the Manhattan project. This will truly give you an idea of what is meant by an "order of magnitude."
