Coding Curves

coding curves


For a number of years, I’ve been wanting to writing a book called “Coding Curves”. There are all kinds of really fascinating curves that are fun to code and understand and create very interesting images. I’ve started this book at least three times. I’m feeling the urge to to it again, but I’m going to be more realistic about it this time. I don’t think I’m going to sit down and write a book cover to cover and get it formatted and edited and self publish it. I’ve accepted that that’s just not going to happen. But I want to write about this stuff.

The Plan

So I’m going to try to do it as a series of blog posts. I don’t know how often these posts will come out. Maybe once a week if I’m diligent. Maybe more often if I get on a roll. Maybe less if I get bored, distracted, or busy with other things. But even if there’s a gap, I can pick back up where I left off and continue.

Maybe, when it’s all done (will it ever be?) there will be enough there to actually compile into a book. Who knows.

Table of Contents

This is the plan. It may differ, but we gotta start somewhere. I’ll link the posts as they come out here, so this post can continue to serve as an index.

  1. Intro (you’re reading it)
  2. Trig Curves
  3. Arcs, Circles, Ellipses
  4. Lissajous Curves
  5. Harmonographs
  6. Pintographs
  7. Parabolas and Hyperbolas
  8. Bezier curves
  9. Cycloids and Trochoids
  10. Spirals
  11. Roses
  12. Guilloche Patterns
  13. Polynomials
  14. Fourier Series

In general we’ll be covering two-dimensional curves. Some of these subjects will take multiple posts to cover. I’ll update the TOC as it evolves. There may be more subjects too, and I’m open to suggestions.

The Format

Most of what I’ve written before has been tailored to a specific language. For example, I wrote Playing With Chaos using JavaScript and HTML 5 Canvas. The idea was that it should be generic enough to convert to any language or platform, but I felt I needed to base it in some concrete language.

After recently reading a couple of really fantastic books on ray tracing (covered here), which were completely language agnostic and only included pseudocode samples, I’ve changed my thinking about this. So all “code samples” in this series will actually be “pseudocode samples”.

So write in whatever language or platform you want. The main requirements will be:

A. The ability to set up and size a canvas or drawing surface of some kind.

B. The ability to draw lines of different colors and widths on said canvas.

C. Typical language features and control structures like functions, variables, for loops, conditionals, etc. We’ll probably need some kind of array or list as well as some structured object type, so we can have a point object that has x and y properties. Most of this is all table stakes for any modern language, though it may look different in each one.

Additionally, it will be nice if you can draw circles (or at least arcs, which can become circles) and rectangles, and be able to fill an area with a given color. Extra credit if your drawing api lets you write text to the canvas.

A simple pseudocode example might look like this:

canvas(800, 800)

setColor(1, 0, 0) // red
moveTo(100, 100)
lineTo(700, 700)

This should output an image like this:

I’ll avoid going as deep as OOP or FP as those can look quite different on different platforms, but we’ll need some functions, so I’ll keep those pretty basic:

canvas(500, 100)

function foo(count) {
  for (i = 0; i < count; i++) {
    moveTo(i * 10, 10)
    lineTo(i * 10, 90)

Resulting in:

A few things to note here.

First, I’m calling the function before it’s defined. That might work in your language, or it might not. If not, you’ll have to rearrange things.

Secondly, the drawing api functions are written like global functions. It’s likely that in your drawing api, these will need to be called as methods of some kind of canvas object, which may have to be passed into the function, or might be able to be defined globally. I’m going to ignore that and assume that you can figure stuff like that out. The focus here is on covering concepts, not best coding practices.

Also, I’m not bothering with types for vars, args or returns, unless in some instance it becomes non-obvious and important.

As I get deeper into the series, my pseudocode style might change somewhat. If so, I’ll come back here and update things.

Wait for it!

Look for the first installment soon!

14 thoughts on “Coding Curves

  1. Cool. Pseudocode, makes sense, equitable. I just had a funny flashback to drawing in PostScript decades ago. 😉

    Realize most of your work here will be 2D, but I’m dreaming/yearning to see this procedural geometry/animation in 3D, especially immersively with headset. Blender first interested me with its Python control over all menu operations, but lately the action seems to be in its Geometry Nodes, a composition method which can be driven by external data. There are older YouTube videos of constructing Sierpinski Gaskets and such, but recent profile-along-curve nodes seem to offer greater procedural freedom.

    Not that I’m nudging you or such… appreciate your work in making this math more accessible!

    1. Depends on the drawing api I guess, but most that I’ve worked with will allow multiple moveTo’s and lineTo’s with a single final stroke. In fact, doing a single stroke is usually a lot faster than doing one for every segment.

  2. I think there’s a small error in the second bit of pseudocode:

    function foo(count) {
      for (i = 0; i < count; i++) {
        moveTo(count * 10, 10)
        lineTo(count * 10, 90)

    moveTo and lineTo should probably reference `i` not `count`

  3. Thanks for the comments about the typo. Fixed now. That’s the one problem with writing in pseudocode. Hard to error check. 🙂 Of course, I write a concrete working example, but sometimes there are errors in copying it over.

  4. Thank you for this. I look forward to the finished book. Since this will be a book some day I thought I should point out that I noticed a typo. Near the end you say, “Also, I’m not bother with types . . . ” Should this be, “Also, I’ll not bother with types . . . ” or, “Also, I’m not bothering with types . . . “

    1. Thanks. Not sure it’ll be a real book, but when all is said and done I might compile it into a pdf/epub and let people download it. I guess that’s a book.

Leave a Reply

Your email address will not be published. Required fields are marked *