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.


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?


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.


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


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
function B {
  do this some more

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

do this
then do this
call function B
do this some more
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

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

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:


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


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.


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.


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


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.


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


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


And again.


And again.


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

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.



Filed under Trube On Tech

“Perfect is the enemy of the good”

Both professionally and as a writer I am bumping up against this aphorism in my current projects.

One of the things they tell you as a writer is to keep revising, keep changing, keep editing, keep making the book better. The same is true of software, though unlike writing often the process is keeping up with changes other people are making that affect your work (I’m looking at you Microsoft).

The first thing I learned as a professional programmer was the difference between the ideal perfect solution, and the practical, applicable, “quick and dirty” solution. On deadline you don’t have time to make flawless code. And truthfully flawless computer code is a lot like haiku’s: not very long and can only express a few things.

Writing is much the same way, especially if you want people to actually read your stuff. Eventually you have to reach the point where it is okay to put something out the door. If you’re constantly rewriting based on your evolving standards (changing user requirements) you will never deliver a product. This is not to say you should send something out that is half finished and buggy. Even though ebooks are becoming more like software in that you can push updates out to everyone who purchased them, you still have to deal with initial market impressions of you. If you become known for making crappy software, or writing crappy books, no amount of post-release revision is going to fix that. Then your only solution is re-branding (maybe a pen name).

So how do you know when something is done? Maybe it’s a fixed number of revisions, or even more practically a release deadline. Maybe it’s finding that fresh beta reader who hasn’t read a lick of the draft and hasn’t already formed impressions of it telling you they love your work. Whatever the case, sometimes you have to accept something is good, and will never be perfect.

How do you decide when something is done, and when it needs a few bug-fixes?

As a side note apparently the above phrase is commonly attributed to Voltaire though it has its origins in ideas from Aristotle and Confucious. Thank you Wikipedia.

1 Comment

Filed under Writing

The Joys Of Technical Writing

If you are a professional engineer, particularly one with a known interest in writing like me, you may be assigned to one of the more dreary forms of writing, technical writing. This can be anything from a project proposal, to a quick start guide, standards document, or the dreaded user manual.

I’m in the middle of drafting one user manual and updating another for my job.

But writing for a technical audience doesn’t have to be boring, and a lot of the tools that may work for your fiction writing project can be applied to your professional life as well. Here are a few tips and tricks I’m trying as I work on this latest “book”.

1. Keep using word count goals – Since writing a technical document can often involve a lot of external work, like taking screenshots, testing procedures, and fixing bugs, this word count goal may be more modest than you think. 1000 words of technical writing may be the equivalent of 3000 words of fiction writing for you. Whatever the ratio is, it’s easier to feel like you’re making progress against what can seem like a gargantuan undertaking if you keep these micro goals.

2. Don’t work too far ahead – There might be a temptation to use your afternoon taking screenshots and planning out the next chapter, rather than continuing to write. Sometimes this is fine, as it gives you an idea of the direction of your next section. But if you want internal consistency in your screenshots, and to show your procedures as a logical progression of one step to the next, you may be better off taking screenshots concurrently with your writing so you don’t have to do as much rework. This can seem disruptive to the writing process, but it reduces the amount you’ll have to go back.

3. Tell a story – If the piece of software is used to build something else, create an example project and use that project throughout the entire manual. Show how each chapter adds features to your project along the way. Be sure to explain everything you think needs explaining, but provide a context for that feature as well. It’s the whole showing not telling thing.

4. Have a little (appropriate) fun – I’m a math geek if you hadn’t guessed so you’ll see more than a few apt puns in example names in my technical writing. A common programming trope is the “Hello World” program or variable names of foo and bar (though these may not be appropriate in all professional contexts). As long as these puns aren’t excessive, and don’t detract from the overall usefulness of the document, they can be a way to make the writing more fun for yourself.

5. Have something else to do – As a software developer there are always bugs to fix and features to tweak. It doesn’t hurt to have a few of these in your back pocket to work on when you really don’t feel like writing. If you have a deadline, be sure you meet it, but make sure you get your brain thinking in different ways too. It will improve both aspects of your work. If you don’t have additional projects of your own, see how you can help someone else (again caveat emptor as your work environment may vary in terms of your freedom of development time).

6. Outline and write sequentially – A user manual will often be referred to in any order, so it’s important that each chapter be able to stand on its own. An outline will give you a sense of what other chapters to reference that are relevant to your topic, and writing sequentially allows for the continuing narratives of examples and back references to topics you’ve already discussed.

7. This is a living document – A fiction writer is used to the idea of revising and revising until something is done. Technical documentation (if it’s to be useful) is never really done. It has versions and revisions like software, and should be periodically updated. That’s why it’s important to have a structure you and others can follow so finding the sections to update is much easier.

What kinds of writing do you do in your professional life?

1 Comment

Filed under Trube On Tech, Writing

Bonus Friday Post “Fractal Valentines Day!”

Many of you have probably seen this old XKCD comic:


But it takes a special brand of geek to see that drawing as a challenge. Here’s my first attempt and its axiom:



Unfortunately, L-Systems aren’t really designed well for curves. You can draw them, but you’ve got to do something like “move forward small amount, turn 1 degree, repeat 180 times”. In L-System code this looks like this:


DF = Move D forward, E+ = Turn 1 degree

But this is Valentine’s Day, and Valentine’s day should be a little hard. So here’s attempt 2:




As you can see a little closer to the mark, but we’ve got some overlap and the heart is kind of pointy at the curve transition. For attempt three I did a trick I used to do with cakes. Take a square, and add two-halves of a circle to two sides:



And then because it’s me, I thought, “can we make the heart just a tidge taller”:



Now most people would stop there, but I played around with a couple of other variants:





And then I thought, well now that I have this heart object, what else can I do with it?




Here’s the code for “Heart 3” my first successful attempt, which works with the programs in Chapter 4 of my book:

<?xml version="1.0">
 <imageAttr prefix="heart3LSys" lvl="6" scaling="0.5"></imageAttr>
 <ruleMappings turnAngle="15" length="250">
 <rule cmd="forward" char="F"></rule>
 <rule cmd="right" char="+"></rule>
 <rule cmd="left" char="-"></rule>
 <rule cmd="begRecr" char="["></rule>
 <rule cmd="endRecr" char="]"></rule>
 <rule cmd="move" char="fg"></rule>
 <transformations axiom="Cg[X]BgA-TfRS-[X]S-RTfA-Bg[X]">
 <replace char="X" replStr="Cg[X]BgA-TfRS-[X]S-RTfA-Bg[X]"></replace>
 <replace char="f" replStr="F"></replace>
 <var char="A" value="9"></var>
 <var char="B" value="4.25"></var>
 <var char="C" value="-4.25"></var>
 <var char="D" value="0.034906585039886591538473815369772"></var>
 <var char="E" value="0.066666666666666666666666666666667"></var>
 <var char="S" value="3"></var>
 <var char="T" value="4"></var>

Technically the “R’s” should be replaced with the whole long string and you can get rid of the R replacement rule, but I left it this way for readability. High-quality versions of the image are available by clicking on the image.

Happy Valentine’s Day, especially to you, the little red-haired girl 😉


Filed under Uncategorized