Tag Archives: Programming

So why fractals?

I’m going to be honest with you about something. I honestly had no idea I’d be sitting here, having already written two fractal books and with ideas for more, across from a shelf packed with reference material. I have more books on fractals than textbooks I saved from my actual degree. In fact, I have three books that basically have the same title:

  • Chaos, Fractals, and Dynamics
  • Chaotic Dynamics and Fractals
  • Chaos, Dynamics, and Fractals

I have a fractal wish list with more than 40 books in it. If you were to list three things you know about me, “likes fractals” is one of those three.

DiamondGem2a_lq

So why do I like fractals, and more importantly, why do I still like them?

As a programmer – Creating fractals has taught me a lot about graphics formats, string management, and handling large amounts of data. I’ve learned new programming languages by trying to write fractal programs. I’ve used some of my color ramp algorithms professionally, and used fractal information as data sets. Simply put, writing fractal programs is challenging, engaging, and a great avenue for learning new things.

As a writer – Fractals can seem like an intimidating area of math. It doesn’t have quite the reputation of say calculus, but a lot of people look at fractals and go “that’s way beyond me.” As someone who owns a shelf full of fractal books, I can say that some of the problem is with how these things are presented. A formal mathematical text isn’t going to draw people in unless they’re already a professional mathematician. Writing about fractals has always presented the challenge for me (as a very technical person) to write about something complicated in an easy-to-understand way. I’m as prone to techno-babble as the next engineer, but if I actually want to get the people around me interested in what I have to say, I need to find better ways to explain it. This is a great challenge for any writer.

As an artist – I’m not a painter like my Mom, but I do like creating cool designs. Creating fractal images can be a very playful and exploratory experience. And unlike a canvas, if I screw up, I can just generate a new image. And I do have my own aesthetic. Fractal calendars have a tendency to make everything over busy, or to shy away from what I would recognize as a fractal. I like clean lines that highlight the natural beauty of the math, without imposing a lot of my own will onto it.

As a publisher – Writing fractal books has taught me more about eBook formatting, finding niche markets, evaluating royalty options and just finishing projects than anything else I’ve done. Fiction can live in a nebulous world of constant revision, whereas non-fiction can have a finite goal and a known finish point.

As a math geek – Fundamentally I just think fractals are cool. They’ve shown me different ways to look at dimension, complex numbers, even how to define a circle. And some of things you can do with the “Chaos Game” and Iterated Function Systems are just so cool. Order rising from randomness. Even more predictable things like L-Systems can always surprise you. You think a design is going to turn out one way, and it ends up looking completely different. And it’s a young area of math, there is still much to be learned and discovered. There’s real territory out there for people to make their mark.

What are you surprised to find has become a focus in your life?

1 Comment

Filed under Writing

The Light, It Burns

For about the last two years the bulbs above my cubicle at work have been blown out, as have many of the others in my part of the office. This resulted in a nice cozy workspace, soft light from my two desk lamps and my computer screens. Not dark, but comfortable.

When I arrived at work this Monday I was dismayed to find that someone had replaced every single blown out bulb, bathing the office in a bright artificial glow. Worse still, because of the placement of my light, the light balance in my cubicle is thrown off, really bright to the left, still kinda dark to the right even when I switch on my desk lights. It’s a sudden and disorienting shift to my environment. It’s giving me a headache.

Now was a writer I pride myself on being able to work anywhere. I have configured my gear and what I carry to make writing on the go a snap. And my work programming environment is tuned to my needs as well. Two screens, whimsical desk decorations and my own coffee maker. I don’t want to be some fragile baby bird who can only survive if the conditions are just right. But like a bird I do like to nest and my cubicle was one of those nests.

My office downstairs at home is comfortable. The desks are a dark color and my three desk lights provide enough illumination for the surfaces but not so much as to blind me. I have the option of an overhead light when I need to see more of my under the desk spaces, and I can easily switch it off when I don’t. The whir of the dehumidifier is comforting to the point that it’s jarring when it isn’t running.

On the go I like dark coffee shops, or book stores with are illuminated but not oppressive. I like white noise, the only thing my office at work still has going for it with all of the blowing fans. The worst place I ever tried to work was my library’s quiet rooms. Bright, quiet and feels like you’re sitting in a tomb.

Part of my annoyance is that the change was sudden and since all of the bulbs are new, they are at the point of being their most oppressive and artificial. The office used to be this bright when I started working here, and truth be told I don’t have that much control over my environment here. I’m trying to get used to it, though I’m seriously considering unscrewing the bulbs or coming to work wearing sunglasses.

Do you like where you work? What makes it a comfortable space for you?

2 Comments

Filed under Uncategorized

Where perfection should be possible

Some people like math because problems have solutions. Most of the time, those solutions can be proved, and the right answer is unequivocally the right answer.

Math might be the only thing that works that way. Writing certainly doesn’t, and neither does programming.

Writing software requires a lot of math, creativity and logical thinking. Like writing books, writing programs have roughly two stages of revision (though in a different order).

The first thing you have to do with a program is get it to compile. Yes, there are interpretive languages like Java, but even those have to obey certain rules of syntax. In other words, your program has to not have any obvious flaws, a misspelled command, a missing semi-colon, etc. This is most akin to copy-editing which is usually one of the last things you do when writing.

Many young programmers make the mistake of thinking a program is finished and working if it compiles, just as many writers think a book is done after they first write it down.

But the next stage of checking a program is testing. My favorite way of saying this is to act like a drunken monkey is randomly hitting the keyboard. In other words, don’t assume that the user has any idea how to use the program properly. Can they still get the desired task done? You shouldn’t test program only in the ways it should be used, but in the countless other ways it could be used, even if those are wrong. Then you write additional code, or fix existing, to make sure the program can deal with all of those drunken monkeys.

This is what the writer does when they rearrange scenes, write bridging scenes, flip chapters, and put the story in front of beta-readers. You may have thought your narrative worked a certain way, but people reading it may show you otherwise, especially people who aren’t inclined toward your genre and its conventions.

But the last and most important stage of any story and any program is getting it out there.

It is impossible to code for every possible contingency, nor is it practical to do so. You could spend a month trying to solve a problem that might waste 5 minutes of 1 person’s time out of a million. That’s time that could be spent creating something else, or fixing the bigger flaws.

And you have to deal with the different ways people look at something. Anyone who’s tried to program cross-browser applications knows there is no perfect solution that looks exactly the same in all of the major web-browsers. We’re crazy enough people to get down to the pixel level and notice that Chrome adds a pixel where Internet Explorer doesn’t. And don’t even get me started about Firefox which insists on doing everything different.

Your readers will function much the same way. The way a scene will look in one person’s mind will play very differently in another’s. There may be ways they’ll look at a passage you would never have even considered. Sometimes this is wonderful and can teach you a lot about your own tendencies, and other times its annoying and you just want that person to shut up.

Whichever it is, you have to decide when a project is done, and what are the best things to fix before moving on to something else. Writing and software can be perpetual activities, but nothing would ever be finished if somebody didn’t throw up their hands and say, it’s done!

Leave a comment

Filed under Trube On Tech, Writing

Everybody can be a programmer (Recursion)

A couple of months ago, President Obama wrote his first lines of code as part of the “Hour of Code” program for National Computer Science week. You can check out his experience here and take a crack at the hour of code yourself at this site. In that spirit, I thought I’d take today to teach you one of the main concepts of programming, recursion.

Recursive logic is something that almost all programmers struggle with at first, and is a source of continued humor. In the glossaries of many computer science book the definition given for recursion is:

Recursion see recursion.

By the end of this post I hope you’ll not only get the joke, but get the concept as well. This is one of the most powerful, elegant ways to code, and it is simple enough that your five year old has already used it.

Recursive algorithms are made up of two parts, a repeated action (or function) and a base case. In programming one way we do a repeated action is a loop. This can be for a fixed amount of time, or until a certain condition is met.

Fixed

counter = 0
while (counter < 100) {
  do something
  counter = counter + 1
}

Conditional

numberOfHeads = 0
while (numberOfHeads < 50) {
  flip a coin
  if (heads) {
    numberOfHeads = numberOfHeads + 1
  }
}

In this example the fixed loop will run 100 times and stop, the conditional loop will run until heads turns up 50 times. The loop repeats everything (in italics) until the while condition is met.

A few quick definitions before we get started. A function is a set of instructions executed in linear (top-down) fashion. It can call (run) other functions. Those called functions run a set of instructions, then return to the function that called them, continuing execution of the calling function after the line where the other function was called.

Examples help:

function A {
  do this
  then do this
  call function B
  finally do this
  return
}
function B {
  do this some more
  return
}

When function A is run the order of execution would be:

do this
then do this
call function B
do this some more
return
finally do this

Now let’s take our coin flipping example and write it as a recursive algorithm. Again a recursive algorithm has both a repeated action and a base case. The repeated action is flipping the coin, and the base case is when we’ve gotten 50 heads.

function flippingCoins(numberOfHeads) {
  flip a coin
  if(heads) {
    numberOfHeads = numberOfHeads + 1
  }
  if(numberOfHeads = 50) { // Base Case
    stop flipping
  }
  else {
    call flippingCoins(numberOfHeads) // Recursive Call
  }
  return
}

The base case (highlighted in bold) is when we get 50 heads. Instead of looping back to the top we call the function from inside itself. For own coin flip example, this doesn’t seem to make much of a difference and looks like a lot more code for a simple loop. But in other cases, this recursive call has a stacking effect. Instead of repeating the same action over and over (like flipping a coin) each recursive call has an effect on the step above it.

Let’s take a look at another example:

function foldPaper(numberOfFolds) {
  fold paper in half
  numberOfFolds = numberOfFolds + 1
  if(numberOfFolds = 4) {
    make cuts
  }
  else {
    call foldPaper(numberOfFolds)
  }
  Unfold Paper
  return
}

This function takes a sheet of paper, folds it in half four times, makes some cuts, then unfolds the paper. Our base case is after we’ve made four folds, and our recursive call is to fold paper. We’ve added one more step to this function which is to unfold the half of paper we just folded at the end of the function.

So our first step is to start with a full sheet of paper:

IMG_3934

Then fold it in half (adding 1 to the number of folds).

IMG_3935

Since we’ve only made 1 fold our base case is not met so we call our function again. Now we’re not starting with a full sheet of paper, since our first function call folded the paper in half, so when we repeat the fold, the paper is now folded in quarters.

IMG_3936

So far we’ve made 2 folds, so our base case is still not met, so we call the foldPaper function again. As before, the foldPaper function starts by folding the paper in half.

IMG_3937

Now we’ve made three folds, we still haven’t met our base case yet, so we call foldPaper one more time.

IMG_3938

After four folds our paper is folded into sixteenth’s and we’ve met our base case. So now we can make a few cuts.

IMG_3939

After we make the cuts we unfold the paper once and start at the place where the previous function called us.

IMG_3940

After the function call to foldPaper returns we unfold the paper again.

IMG_3943

And again.

IMG_3944

And again.

IMG_3942

Remember, functions execute top to bottom. Here’s what our full function call would look like.

Call foldPaper
  fold paper in half
  Call foldPaper
    fold paper in half
    Call foldPaper
      fold paper in half
      Call foldPaper
        fold paper in half
        cut paper
        unfold paper
        return to foldPaper
      unfold paper
      return to foldPaper
    unfold paper
    return to foldPaper
  unfold paper
end

The cuts were only made once but had an effect based on the number of times the paper was folded. If the paper was folded one less, or one more times, the resulting image would have been different, and each fold had an effect on the first one. And the unfold paper step had to happen for us to be able to see that image, but only after the cuts had been made.

If this had been a loop it would have been like that coin flip, folding a full sheet of paper in half each time. We’d never see the smaller and more intricate patterns.

Hopefully now you’ve got some basic understanding of what recursion can do or at least how it works. If you understand this, then you’re well on your way to becoming a great programmer.

 

2 Comments

Filed under Trube On Tech