newstalk

Randomness.

bq. To say that something is random is to say that you do not understand it.

I made this statement a “few posts back”:http://http://newstalk.eykd.net/oldspeak/2004/12/01/notes-for-a-discussion-on-evolution/, and I think this is a good time to qualify it, because it’s come up again. Sit back and relax, because to unpack this concept, a story is required.

So, I’m using a piece of software called “yWriter”:http://www.spacejock.com/yWriter.html to organize the novel that I’m working on. yWriter has a feature for taking a text outline (using some simple markup) and turning it into a project broken down by chapter and scene. The particulars aren’t important. What matters is, I had found a bug. When I tried to generate a project from an outline, yWriter crashed. What to do? What I did first was to go find the author’s contact info so I could submit a bug report. This is just being a good neighbor. Simon maintains yWriter (and a number of other useful applications) for free. He doesn’t have a QA(Quality Assurance) staff to bug-test his software, so it’s all up to him, and anyone who decides to help.

However, as I started to write my bug report, I realized it would be next to useless for him unless I could give him as specific a description of the problem, and a way to reproduce it. All I knew is, when I clicked the “Generate Project” button, yWriter gave me specific error message, then rolled over and died. So I started running test cases, based on my original input, to see if I could narrow down what had thrown things off kilter.

Going in, my assumption was that some odd combination of my input had caused the parser to do something illegal. So, I started from the beginning of my input. Chapter 1 and Scene 1 go in. Click the “Generate Project” button. Voila! It works! This is good. Okay, Chapter 1, Scenes 1 and 2. Click. Works. Chapter 1, Scenes 1, 2, and 3. Click. Works. Chapter 1, Scenes 1, 2, 3, Chapter 2, Scene 1. Click. Works.

Rinse, wash, repeat. (This is why QA(Quality Assurance) guys get paid the big bucks.) Then, I add on Chapter 3, Scene 1 to the input. Click. Whomp. Error #9! Error #9! Subscript out of Range! yWriter rolls over and dies. I had something!

I’ll skip the boring details, because, well, it’s boring no matter how many exclamation points I add to it. What happened was this: continuing to adjust my input in a fairly systematic manner, I found that the very same text seemed to work just fine on one trial, then roll over and die on the next. After 15 minutes more of this, I began to get very frustrated. I couldn’t find a pattern. The bug appeared to be completely random, with no way to confidently reproduce it. I went back and started from Chapter 1, Scene 1 again. This time, trials that had worked before now failed. My brain reeled To quote Douglas Coupland:

bq. Subjected to the random, [I] acknowledge [my] inability to comprehend logic and linear systems.

After banging my head against a brick wall for a good long while, I finally stopped, stepped back, and looked around. I was obviously missing something. The way that computers and software are designed, you have to work hard to be random! By nature, they are deterministic: give a computer the same input and environment, you will get the same output. That’s just how it works. If I was getting “random” output, then either my input or the environment were changing.

Based on my limited knowledge of Windows and GUI programming, I felt I could safely rule out environment. Although I’ve never seen the code for it, I knew that yWriter is a simple program, and it interacts with its environment in a limited fashion. In my trials I had taken certain steps to ensure that the environment wasn’t changing between steps.

To give an example of a program on the opposite end of the spectrum from yWriter, consider Microsoft’s Internet Explorer. Here is an application that is very large and complex, with millions of ways in which it interacts with its environment(s). This is part of the reason why we’re always hearing in the news about new security holes being found with the darned thing, because there are any number of unexpected ways that Internet Explorer can interact with input and environment, ways that IE’s programmers never considered, or did not consider fully.

This is also why the weather is so hard to predict. There are myriad factors that affect the weather, and we’ve discovered only a small set of those factors. So, we have our model of how we think the weather is supposed to happen, based on the factors we know about and can observe. Then, some of those other factors that we don’t know about rear their ugly heads, and Voila! Chaos.

If you’ve seen Jurassic Park, then you’ve probably heard of chaos theory, also known as complexity theory. All that the mumbo-jumbo is really getting at is the admission that the world is complex, and never do we know all the contributing factors to any given phenomenon. But the theory also relies on the faith that, although the world may seem chaotic, the unexpected is simply the result of unexpected interactions between known and unknown factors, and if enough factors are known, the unexpected interactions can be reduced and the model refined, the same way on an old radio tuner you can home in on a weak signal until you can understand the radio announcer’s voice above the background static. Not perfectly, but well enough.

So, back to my little problem. I had concluded that the environment couldn’t be the problem, so it still had to be a factor of my input that I had not considered. I went back to my original sticking point and toyed with it some more. Thinking back on my trials, I realized that I had not been entirely systematic with my input. In the tedium of the chore, I had played fast and loose, skipping around some. Here was my clue.

In the skipping around, sometimes I left a newline at the end of the input, and sometimes I didn’t. It took only half a second to put this new factor to the test. Eureka! If the input ended with a newline, it worked perfectly. If I did not end with a newline, it rolled over and died. Incidentally, this is a common issue with text parsers. If you’re configuring a Linux box, for instance, most configuration files require a newline at the end of the file. I finished writing my bug report and sent it off, with a thank-you to Simon for his hard work on yWriter.

So ends my story, and I hope the moral is a bit clearer now. What I had initially felt to be a “random” phenomenon was simply the result of a system which I had not understood fully. Understanding the system and refining my input resulted in a completely(?) predictable system, at least as far as generating outlines go. So, the next time you find yourself frustrated with something (not just a computer, but most anything) that isn’t working in a predictable fashion, stop, take a step back, and start looking for factors that you haven’t accounted for yet. Remember: nothing is random; everything happens for a reason.

h4. Updated

By the time I had finished writing this post, Simon had fixed the bug and sent me a new build. Something tells me that you’re not going to get that kind of service from Microsoft. The new build should be up on “his site”:http://www.spacejock.com/yWriter_Version.html soon. Thanks, Simon!

Possibly related:

Share this: