## Mathematics and Digital Art: Final Update (Fall 2017)

Yes, it is the end of another semester of Mathematics and Digital Art!  It was a very different semester than the first two, as I have mentioned in previous posts, since I began the semester with Processing right away.  There are still a few wrinkles to iron out — for example, we had a lab project on interactivity (involving using key presses to change features of the movie as it is running) which was quite a bit more challenging than I expected it would be.  But on the whole, I think it was an improvement.

So in this final post for Fall 2017, I’d like to share some examples of student work.  In particular, I’ll look at some examples from the Fractal Movie Project, as well as examples of Final Projects.

Recall that the Fractal Movie Project involves using linear interpolation on the parameters in affine transformations in order to make an animated series of fractal images.  One student experimented with a bright color palette against a black background.  As the fractal morphed, it actually looked like the red part of the image rotated in three dimensions, even though the affine transformations were only two-dimensional.

Cissy wanted to explore the motion of rain in her movie.  Although she began with bright colors on a black background, once she saw her fractal in motion, she decided that more subtle colors on a white background would be better suited to suggest falling raindrops being blown about by the wind.

Sepid also incorporated movement in her movie — she created a rotating galaxy with a color palette inspired by the colors of the Aurora Borealis.  In addition, she learned how to use the Minim library so she could incorporate sound into her movie as well.  Here is a screen shot from her movie.

Now let’s take a look at a few Final Projects.  Recall that these projects were very open-ended so that students could go in a direction of their choice.  Some really got into their work, with truly inspirational results.  The presentation that Sepid gave at a recent meeting of the Bay Area Mathematical Artists was actually work she was doing on her Final Project (read about it here).

Terry took on an ambitious project. She based her work on a Bridges paper by Adam Colestock, Let the Numbers Do the Walking: Generating Turtle Dances on the Plane from Integer Sequences (read the paper here).  Terry did have some programming experience coming into the course, and so she decided to code all of Adam’s turtle graphics algorithms from scratch! This was no simple task, but she worked hard and eventually accomplished her goal.

Here is a screen shot from one of her movies; Terry wanted to create an interesting visual effect by overlaying multiple copies of the same turtle path.  Since this particular path was not too dense in the plane, she was able to work with thicker lines.

Tera created a movie which involved rotating triangles and moving dots.  Her movie had a strong sense of motion, and incorporated a vibrant color palette. She remarked that working with color in this project was both fun and quite challenging. In her words, “Playing nicely with hot pink is not an easy feat.”

I would also like to share the fact that Professor Roza Aceska of Ball State University (Muncie, Indiana) will be teaching a course about digital art next semester using Processing which will be incorporating a lot of my course materials.  I am very excited about this!  Many faculty who come to my talks say they are interested in teaching such a course, but getting Department Chairs and Deans to approve such courses is sometimes an uphill battle.

Professor Aceska’s course will be a bit different from mine — her course is in the Honors Program, and as such, does not count as a mathematics credit.  So she will not have most of the mathematics assignments and quizzes that I had in my course.  But she will still be emphasizing the fascinating relationship between mathematics, programming, and art.  I hope to write more about her course sometime during the next semester.

One final remark — I am helping to organize a Mathematical Art Exhibition at the Golden Section Meeting of the Mathematical Association of America on February 24, 2018 at the California State University, East Bay.  So if you’re reading this and are in the Bay Area and would like to submit some mathematical art for inclusion in our exhibit, please let me know!

## On Coding XIII: Retrospective.

I published the first installment of On Coding on September 11, 2016.  It seems a bit surreal that this thread is over a year old — but all good things must come to an end.  I really enjoyed writing these posts; they helped me organize my thoughts about my own personal coding history.

But there are some loose ends I’d like to tie up.  I’ve had brief forays into other languages — too brief to devote an entire post to any one of them.  I’ve mentioned a few of them here and there, but I’d like to take the opportunity to include them all in one post.

Before doing so, I should mention that Processing is my most recent programming adventure.  But I have written so much about using Processing in the context of my digital art course, I don’t feel the need to devote a separate post to it.  And I feel I might bore you, dear reader….

The first is PASCAL, which I first learned while taking an undergraduate programming class.  Other than the course, I only did a few other things with PASCAL.  I did write a routine that printed out 4 x 4 magic squares — I was really into magic squares back in college.  I also dabbled with computer graphics and geometrical inversion — I recall giving a talk where I discussed geometrical inversion, and I split the screen so on one side you saw lines tangent to a conic section, while on the other side, you saw inverse circles tangent to the inverse limaçon.

While in graduate school, I had a one-year stint filling in for a faculty member at a nearby college, and I taught a data structures course using PASCAL.  Now, I would never think of PASCAL as a go-to language for any particular purpose.  It’s still around, but not nearly as popular as it was then.

The next is LISP*, which I used while teaching at a summer program during graduate school.  This was a parallel version of LISP written for the Connection Machine, a state-of-the-art supercomputer in its day.  It had literally thousands of different processors, each very simple.  But because of the sheer number of processors, the speed of the Connection Machine merited it the designation “supercomputer.”

The language was quite similar to LISP, except that many functions had parallel versions which could be executed on each processor.  I can’t recall much of what I did on the Connection Machine, but I do remember programming Conway’s Game of Life on a 1000 x 1000 torus.  Of course I can do that on my laptop right now in Mathematica, but at the time, it was a real feat!  Remember, that was back in the day when Mandelbrot sets were calculated pixel by pixel and computers were so slow you could actually see the pixels march right on by….

Chronologically, Maple — a direct competitor of Mathematica — comes next, sort of…I used Maple around the same time as LISP*.  I seem to recall the only reason I played around with it was that I had a house-sitting job for a few summers, and there was a computer I could use which had Maple on it.

I recall finding Maple really useful, but there was a bit more syntax than with Mathematica.  I really like Mathematica‘s fundamental data type — the list, just like LISP.  But I think part of the reason I’ve stuck with Mathematica through the years is that most places I’ve been have supported it — and being free is a big advantage.  I know Maple has changed a lot since I last used it, so I don’t feel I’m able to say more about a comparison with Mathematica than what I’ve already said.

Jump ahead a few years to C++.  I can’t remember exactly when I started learning it, but I was teaching at a small liberal arts college, and a colleague who usually taught an algorithms course was going on sabbatical.  I was really the only other faculty member at the university qualified to teach it, and so there it was!  The students in the course knew C++, so I needed to learn it, too….

Well, I should say I learned enough to write code for an introductory algorithms course, which means I didn’t have to dive too deeply in.  I can’t say I used C++ for much after I taught the course, except I remember writing some routines to do financial planning.  You know, like if you have different investments at different interest rates for different numbers of years, etc., how much will you have when you retire?  (Being a mathematician, I thought it insane that I should pay someone else to do my financial planning, so I read everything I could on the topic and did it myself.)  But I haven’t used C++ since.

Last — and perhaps least — there’s Java.  I learned Java was when I was applying for a job teaching mathematics and computer science, and the language taught was Java.  I had never written a line in Java before, and there was some concern that I wasn’t qualified.

So I wrote a little interactive game based on some puzzles I created, which was really quite nice, if I must say.  The only way to show you know how to code in a language is to code, so I did it.

It was rather unpleasant, though.  What I needed to do was really just algorithmic, and the object-orientedness of Java and the need to precisely define data structures really got in the way.  I hope never to write another line of Java again.  (Incidentally — long story — I was offered the job but turned it down.  Saved me from teaching Java….)

And I think that’s about it!  If I can leave you with anything after this series, it’s GO CODE!  Learn as many different types of languages as you can.  The best way to learn is to find something you really want to do, and then go for it.

Remember, my first programming language was Fortran — using punch cards.  Running batch jobs.  Today, you’ve got laptops and the internet.  The only limit is your imagination….

## On Coding XII: Python

It has been some time since I wrote an installment of On Coding.  It’s time to address one of my more recent programming adventures:  Python.  I started learning Python about two-and-a-half years ago when I began teaching at the University of San Francisco.

One of my colleagues introduced me to the Sage environment (now going by “CoCalc”) as a place to do Mathematica-like calculations, albeit at a smaller scale.  Four features were worthy of note to me:  1)  you could do graphics;  2)  you could write code (in Python);  3)  you could run the environment in your browser without downloading anything;  and 4)  it was open source.

For me, this was (at the time) the perfect environment to develop tools for creating digital art which I could freely share.  Yes, I had thousands of lines of Mathematica code, but Mathematica is fairly expensive.  I wanted an environment which would be easily accessible to students (and my blog followers!), and Sage fit the bill.

So that’s why I started learning Python — it was the language I needed to learn in order to use Sage.

For me, two things were a challenge.  The first was how heavily typed Python is.  In Mathematica, the essential data structure is a list, just like in LISP.  For example,

{1, 2, 3}

is a list.  But that list may also represent a vector in three-dimensional space — even though it would look exactly the same.  It may also represent a set of numbers, so you could calculate

Intersection[{1, 2, 3}, {3, 4, 5}].

In Python you can create a list, tuple, or set, as follows:

list([1, 2, 3]),  tuple([1, 2, 3]), set([1, 2, 3]).

And in Python, these are three different objects, none equal to any other.  I don’t necessarily want to start a discussion of typed vs. untyped languages, but when you’re so used to using an untyped language, like Mathematica, you are constantly wondering if the argument to some random Python function is a list, tuple, or….

Second, Python has a “return” statement.  In languages like LISP and Mathematica, the value of the last statement executed is automatically returned.  In Python, you have to specify that you want a value returned by using a return statement.  I forget this all the time.

And while not a huge obstacle, it does take a little while to get used to integer division.  In Python, 3/4 = 0, since when you divide integers, the value of the fraction is the quotient when considered as integer division.  But 3/4. = 0.75, since adding the decimal point after the 4 indicates the number is a floating point number, and so floating-point arithmetic is performed.

Of course, if you’ve been reading recent posts, you know I’ve moved from Sage entirely to Processing in my Mathematics and Digital Art course.  You can read more about that decision here — but one key feature of Processing is that there’s a Python mode, so I was able to take work already done in Sage and adapt it for Processing.

It turns out that this was not as easy as I had hoped.  The essential difficulty is that in Sage, the bounding box of your image is computed for you, and your image is appropriately scaled and displayed on the screen.  In Processing, you’ve got to do that on your own, as well as work in a space where x– and y-coordinates are in units of pixels, which is definitely not how I am used to thinking about geometry.

I am finding out, however — much to my delight and surprise — that there are quite a few functional programming aspects built into Python.  I suspect there are many more than I’m familiar with, but I’m learning them a little at a time.

For example, I am very fond of using maps and function application in Mathematica to do some calculations efficiently.  Rather than use a loop to, say, add the squares of the numbers 1– 10, in Mathematica, you would say

Plus @@ (#^2& /@ Range[10])

The “#^2&” is a pure function, and the “/@” applies the function to the numbers 1–10 and puts them in a list.  Then the function “Plus” is applied, which adds the numbers together.

There is a similar construct in Python.  The same sum of 385 can be computed by using

sum([(n + 1)**2 for n in range(10)])

OK, this looks a little different, but it’s just the syntax.  Rather than the “#” character for the variable in the pure function, you provide the variable name.  The “for” here is called list comprehension in Python, though it is just a map.  Of course you need “(n + 1),” since Python always starts at 0, so that “range(10)” actually refers to the numbers 0–9.  And the “sum” function can take a list of numbers as well.  But from a conceptual level, the same thing is going on.

The inherent “return” in any Mathematica function does find its way into Python as well. Let’s take a look at a simple example:  we’ll write a function which computes the maximum of two numbers.

Now you’d probably think to write:

This is the usual way of defining “max.”  But there’s another way do to this in Python.

print 3 > 2,

you’ll see “True.”  But you can also tell Python to

print (3 > 2) + 7

and get “8.”  What’s going on here is that depending on the context, “3 > 2” can take on the value “True” or “1.”  Likewise, “3 < 2” can take on either the value “False” or the value “0.”

This allows you to completely sidestep making Boolean checks.  Consider the following definition.

This also works!  If in fact a >= b, you return the value 1 * a + 0 * b, which gives you a — the maximum value when a >= b.  And when a < b, you return b.  Note that when a = b, both are the maximum, so we could just as well have written

I think this is a neat feature of Python, which does not have a direct analogue in Mathematica.  I am hoping to learn many other intriguing features like this as I dive deeper into Python.

Python is my newest language, and I have yet to become “fluent.”  I still sometimes ask the internet how to do simple things which would be at my fingertips in Mathematica.  But I do love learning new languages!  Maybe in a year or so I’ll update my On Coding entry on Python with a flurry of new and interesting things I’ve learned….

## Mathematics and Digital Art: Update 2 (Fall 2017)

We’ve just completed Week 8 of the Fall semester, so it’s time for the next update on my Mathematics and Digital Art class!  As I had mentioned before, the major difference this semester was starting with Processing right from the beginning of the semester.

It turns out this is making a really big difference in the way the class is progressing.  The first two times I taught the course, I had students work in the Sage environment for the first half of the semester.  The second half of the semester was devoted to Processing and student projects.

Because students only started to learn Processing at the same time they were diving into their projects, they were not able to start off with a Processing-based project.  As it happened, a few students actually incorporated Processing into their final projects as the second half of the semester progressed, but this was the exception, not the rule.

But last week, we already started making movies in Processing!  Starting simply, of course, with the dot changing colors.

This was a bit easier to present this time around, since we already had a discussion of user space vs. screen space earlier in the semester.  So this time, I could really focus on linear interpolation — the key mathematical concept behind making animations.

Next week will be a Processing-intense week.  I’ll delay some topics — like geometric series — to a little later in the course so we can get more Processing in right now.  The reason?  I really think many students will involve Processing in their final projects in a significant way.  I want to make sure they have enough exposure to feel confident about going in that direction for their final projects.  I’ll let you know what happens in this regard in my next update of Mathematics and Digital Art.

Now for some examples of student work!  For the assignment on iterated function systems, students had three different images to submit.  The first was a Sierpinski triangle — I asked students to create an image simultaneously as close to and as far away from a Sierpinski triangle as possible.  The idea was that a viewer should recognize the image as being based on a Sierpinksi triangle, but perhaps only after staring at it for thirty seconds or so.

This is Sepid’s take on the assignment.  On many of her pieces, she experimented with different ways to crop the final image.  This has a significant effect on the image’s final appearance.

This is Cissy’s submission for the Sierpinski triangle.  In this piece (and the others submitted for this assignment), Cissy remarked that she really enjoyed experimenting with color.  I commented that I thought color choices were among the most difficult decisions to make as far as elements of a work of digital art are concerned.

The second piece was to involve only two affine transformations.  This is often a challenge for students, but there really is an enormous variety of images that may be created using just two transformations.  In addition, one of the transformations needed to involve a rotation by a non-trivial angle (that is, not a multiple of 45°), and students needed to submit a picture of their calculations as well.

One student was trying to create an image that looked like an animal footprint.  She remarked that she did consider a different color palette, but in the end, preferred to go with monochromaticity.

Interestingly, Terry also used a simple color palette.  She remarked that it was challenge to use just two transformations — and because of this minimalist requirement, decided to go with a minimalist color palette.  In addition, her resulting fractal reminded her of birds, so she set the fractal against a white moon and gray sky.

For the third submission, there were no constraints whatsoever — in fact, I encouraged students to be as creative as possible.  There was a very wide range of submissions.  One student was fairly minimalistic, using a highly contrasting color palette.

Jack’s piece was also fairly minimalistic.  I should remark that we took part of a lab one day for students to do some online peer commenting; Jack (and others as well) remarked that he used the advice of another student to improve an earlier draft of his piece.  In particular, he adjusted the stroke weight to increase the intensity of the colors.

Tera based her work on the Sierpinski triangle,  but also included reflections of each of the three smaller components of her version of the Sierpinski triangle.  She remarked that the final image reminded her of a snowflake, or perhaps a Christmas sweater.

Alex’s inspiration came from The Great Wave off Kanagawa, by Katsushika Hokusai.

First, he created the fractal image, experimenting with various color combinations.  When he was satisfied with his palette, he added the boat and the white circle to suggest a black moon.  A rather interesting approach!

As you can see, I’ve got quite a creative class of students who are willing to experiment in many different ways.  It’s interesting for me, since there is no way to predict what they’ll create next!  I look forward to seeing what they create when they really dive deeply into Processing and begin making animations.

In the next update, I’ll report on how students involve Processing in their project proposals.  In addition, they will have submitted their fractal movie projects by then, so there will undoubtedly be many interesting examples of student work to exhibit.  Stay tuned!

## Mathematics and Digital Art: Update 1 (Fall 2017)

About a month has passed since beginning my third semester of Mathematics and Digital Art!  As with last semester, I plan on giving updates about once a month to discuss changes in the course and to showcase student work.

The main difference this semester (as I discussed a few weeks ago) was starting with Processing right from the beginning.  From my perspective, the course has run more smoothly than ever — and some of my students are already really getting into the coding aspect of creating digital art.

I do believe that beginning this way will pay off when we get to making movies.  Since we’ll already know the basics and understand the difference between user space and screen space, I can focus more on the interactive abilities of Processing — such as having features of the displayed image change by moving the mouse or pressing different keys on the keyboard.

The first two assignments were essentially the same as last semester.  We began with discussing color and the work of Josef Albers, emphasizing the fact that there is no such thing as “pure color” — colors are only perceived in relation to other colors.

Again, I was surprised by the diversity of the images students created.  Like last year, a few students experimented with a minimalist approach.  Here is what Alex generated using just a 2-by-2 grid of squares.

I should point out that outlining the geometrical objects (using the strokeWeight function) is not “pure” Albers — you aren’t really seeing one color on top of another due to the black outlines.  But I did have students submit three pieces, insisting that one of the pieces was created only by changing the parameters in the original Albers routine, as shown in the following submission.

Here is Courtney’s submission on this theme, again created only by changing parameters to the drawing routine.

Most students — I think in part due to the fact that we started discussing code even earlier than previous semesters — really pushed the geometry far beyond the simple idea of rectangles within rectangles.

While toying with various geometrical motifs, Tera found something that reminded her of a rose.  This influenced her color palette:  reds and pinks for the flowers, with a green background, meant to suggest that the flowers were in a garden.

Cissy explored the geometry as well.  Note how keeping the stroke weight at zero — so that the geometrical objects have no outline — creates a more subtle effect, especially since the randomness from the dominant color is not too pronounced.

The second art assignment, as in the previous semesters, was to explore creating textures using randomness in both color and shape.  As with the first assignment, I wanted students to submit one piece which involved only changing the parameters to a given function.  In this case, the function created a grid of gray circles, with both the intensity of the gray and the size of the circles having some degree of randomness.  I think it is important that students do some work within given constraints — it really challenges their creativity.  Here is Terry’s piece along these lines.

The second piece was based on a function which created a grid of squares of the same size, but random colors.  Here, there were no constraints — students could modify the geometry in any way they wanted to.  Several were quite creative.  For example, Sepid approached this task by choosing both shape and color to create an image reminiscent of a stained glass window.

The third piece involved a color gradient (see my previous posts on Evaporation).  If you look back at these posts, you’ll recall that a color gradient can be created by increasing the randomness of the colors as you move from the top of the image to the bottom using a power function:  $f(y)=y$ corresponds to a linear gradient, $f(y)=y^2$ corresponds to a quadratic gradient, etc.  Different effects can be created by varying the exponent.

As I was discussing this in class, one student asked what would happen if you used a negative exponent.  I had never thought about this before!  Jack used this idea in his piece, which he said reminds him of looking at a fire.

It turns out that using a negative exponent creates a gradient beginning with black on the top.  Why is this?  As the image proceeds lower down the screen, the algorithm subtracts values from the RGB parameters proportional to $y^n,$ where $y=0$ corresponds to the top of the image, and $y=1$ corresponds to the bottom of the image.

So if the exponent $n$ is positive, there is very little randomness subtracted.  But if the exponent is negative, a lot of randomness is subtracted, since now the numbers near 0 are on the denominator.  Because the RGB values only go up to 255, subtracting a large degree of randomness leaves nothing left — in other words, black.  Now some of the numbers will end up being negative  near the top– but putting all negative numbers in a color specification in Processing does in fact give you black.

Another student also worked with yellows and reds to imitate fire in another way.  Instead of making small circles, he made larger circles with quite a bit of overlap, creating a rather different effect.

And Rosalie found in interesting say to create stripes with the algorithm.  I had not seen this effect before.

So that’s it for the first update of the Fall 2017 installment of Mathematics and Digital Art.  As you can see, my students are already being quite creative.  I look forward to seeing their work develop as the semester progresses!

## Using Processing for the First Time

While I have discussed how to code in Processing in several previous posts, I realized I have not written about getting Processing working on your own computer.  Naturally I tell students how to do this in my Mathematics and Digital Art course.  But now that I have started a Digital Art Club at the University of San Francisco, it’s worth having the instructions readily accessible.

The file I will discuss may be used to create an image based on the work of Josef Albers, as shown below.

See Day002 of my blog,  Josef Albers and Interaction of Color, for more about how color is used in creating this piece.

As you would expect, the first step is to download Processing.  You can do that here.  It may take a few moments, so be patient.

The default language used in Processing is Java.  I won’t go into details of why I’m not a fan of Java — so I use Python mode.  When you open Processing, you’ll see a blank document like this:

Note the “Java” in the upper right corner.  Click on that button, and you should see a menu with the option “Add Mode…”  Select this option, and then you should see a variety of choices — select the one for Python and click “Install.”  This will definitely take a few minutes to download, so again, be patient.

Now you’re ready to go!  Next, find some Processing code written in Python (from my website, or any other example you want to play around with).  For convenience, here is the one I’ll be talking about today:  Day03JosefAlbers.pyde.  Note that it is an Open Office document; WordPress doesn’t let you upload a .pyde file.  So just open this document, copy, and paste into the blank sketch.  Be aware that indentation is important in Python, since it separates blocks of code.  When I copied and pasted the code from the Open Office document, it worked just fine.  But in case something goes awry, I always use four spaces for successive indents.

Now run the sketch (the button with the triangle pointing to the right).  You will be asked to create a new folder; just say yes.  When Processing runs, it often creates additional files (as we’ll see in a moment), and so keeping them all in one folder is helpful.  You should also see the image I showed above; that is the default image created by this Processing program.

Incidentally, the button with the square in the middle stops running your sketch.  Sometimes Processing runs into a glitch or crashes, so stopping and restarting your sketch is sometimes necessary.  (I still haven’t figured out why it crashes at random times.)

Next, go to the folder that you just created.  You should see a directory called “frames.”  Inside, you should see some copies of the image.

Inside the “draw” function, there is a function call to “saveFrame,” which saves copies of the frames you make.  You can call the folder whatever you want; this is convenient, since you might want to make two different images with the same program.  Just change the folder name you save the images to.

A word about the syntax.  The “####” means the frames will be numbered with four digits, as in 0001.png, 0002.png, etc.  If you need more than 10,000 frames (likely you won’t when first starting), just add more hashtags.  The “.png” is the type of file.  You can use “.tif” as well.  I use “.tif” for making movies, and “.png” for making animated gifs.  There are other file types as well; see the documentation on saveFrame for more details.

Now let’s take a look at making your own image using this program.

If you notice, there are lines labelled “CHANGE 1” to “CHANGE 6” in the setup and draw functions.  These are the only lines you need to change in order to design you own piece. You may tweak the other code later if you like.  But especially for beginning programmers, I like to make the first examples very user-friendly.

So let me talk you through changing these lines.  I won’t bother talking about the other code right now — that would take some time!  But you don’t need to know what’s under the engine in order to create some interesting artwork….

CHANGE 1:  The hashtags here, by the way, indicate a comment in your code:  when your program runs, anything after a hashtag is ignored.  This makes it easy to give hints and provide instructions in a program (like telling you what lines to change).  I created a window 800 x 600 pixels; you can make it any size you want by changing those numbers. The “P2D” just means you’re working with a two-dimensional geometry.  You can work in 3D in Processing, but we won’t discuss that today.

CHANGE 2:  The “sqSide” variable indicates how big the square are, in units of pixels.  The default unit in Processing is always pixels, so if you want to use another geometry (like a Cartesian coordinate system), you have to convert from one coordinate system to another.  I do all this for you in the code; all you need to do is say how large each square is.  And if you didn’t go back and read the Josef Albers piece, by “square,” I mean a unit like this:

CHANGE 3, CHANGE 4:  The variables “sqRows” and “sqCols” indicate, as you would expect, how many rows and columns are in the final image.  Since I have 15 rows and the squares are 30 pixels on a side, the height of the image is 450 pixels.  Since my window is 600 pixels in height, this means there are margins of 75 pixels on the top and bottom.  If your image is too tall (or too wide) for the screen, it will be cropped to fit the screen.  Processing will not automatically resize — once you set the size of the screen, it’s fixed.

CHANGE 5:  The “background” function call sets the color of the background, using the usual RGB values from 0-255.

CHANGE 6:  The first three numbers are the RGB values of the central rectangles in a square unit.  The next three numbers indicate how the background colors of the surrounding rectangles change.  (I won’t go into that here, since I explain it in detail in the post on Josef Albers mentioned above.  The only difference is that in that post, I use RGB values from 0-1, but in the Processing code here, I use values from 0-255.  The underlying concept is the same.)

The last (and seventh) number is the random number seed.  Why is this important?  If you don’t say what the random number seed is (the code does involve choosing random numbers), every time you run the code you will get a different image — the computer just keeps generating more (and different) random numbers in a sequence.  So if you find an image you really like and don’t know what the seed is, you’ll likely never be able to reproduce it again!  And if you don’t quite like the texture created by using one random seed, you can try another.  It doesn’t matter so much if you have many rows and columns, but if you try a more minimalist approach with fewer and larger squares, the random number seed makes a big difference.

OK, now you’re on your own….  This should be enough to get you started, and will hopefully inspire you to learn a lot more about Python and Processing!

## To Processing I

I made a decision last week to abandon using Sage (now called CoCalc) as a platform in my Mathematics and Digital Art class.  It was not an easy decision to make, as there are some nice features (which I’ll get to in a moment).  But now any effective use of Sage comes with a cost — the free version uses servers, and you are given this pleasant message:  “This project runs on a free server (which may be unavailable during peak hours)….”

This means that to guarantee access to CoCalc, you need a subscription.  It would not be prohibitively expensive for my class — but as I am committed to being open source, I am reluctant to continue putting sample code on my web page which requires a cost in order to use.  Yes, there is the free version — as long as the server is available….

When I asked my students last semester about moving exclusively to Processing, they responded with comments to the effect that using Sage was a gentle introduction to coding, and that I should stick with it.  I fully intended to do this, and got started preparing for the first few days of classes.  I opened my Sage worksheet, and waited for it to load.  And waited….

That’s when I began thinking — I did have experiences last year where the class virtually came to a halt because Sage was too slow.  It’s a problem I no longer wanted to have.

So now I’m going to Processing right from the beginning.  But why was I reluctant in the past?

The issue is that of user space versus screen space.  (See Making Movies with Processing I for a discussion of these concepts.)  With Sage, students could work in user space — the usual Cartesian coordinate system.  And the programming was particularly easy, since to create geometrical objects, all you needed to do was specify the vertices of a polygon.

I felt this issue was important.  Recall the success I felt students achieved by being able to alter the geometry of the rectangles in the assignment about Josef Albers and color.  (See the post on Josef Albers and Interaction of Color for a refresher on the Albers assignment.)

Most students experimented significantly with the geometry, so I wanted to make that feature readily accessible.  It was easy in Sage, the essential code looking something like this:

What is happening here is that the base piece is essentially an array of rectangles within unit squares, with lower-left corners of the squares at coordinates (i, j).  So it was easy for students to alter the polygons rendered by using graph paper to sketch some other polygon, approximate its coordinates, and then enter these coordinates into the nested loops.

Then Sage rendered whatever image you created on the screen, automatically sizing the image for you.

But here is the problem:  Processing doesn’t render images this way.  When you specify a polygon, the coordinates must be in screen space, whose units are pixels.  The pedagogical issue is this:  jumping into screen space right at the beginning of the semester, when we’re just learning about colors and hex codes, is just too big a leap.  I want the first assignment to focus on getting used to coding and thinking about color, not changing coordinate systems.

Moreover, creating polygons in Processing involves methods — object-oriented programming.  Another leap for students brand new to coding.

The solution?  I had to create a function in Processing which essentially mimicked the “polygon” function used in Sage.  In addition, I wanted to make the editing process easy for my students, since they needed to input more information this time.

In Processing — in addition to the number or rows and columns — students must specify the screen size and the length of the sides of the squares, both in pixels.  The margins — xoffset and yoffset — are automatically calculated.

Here is the structure of the revised nested for loops:

Of course there are many more function calls in the loops — stroke weights, additional fill colors and polygons, etc.  But it looks very similar to the loop formerly written in Sage — even a bit simpler, since I moved the translations to arguments (instead of needing to include them in each vertex coordinate) and moved all the output routines to the “myshape” function.

Again, the reason for this is that creating arbitrary shapes involves object-oriented concepts.  See this Processing documentation page for more details.

Here is what the myshape function looks like:

The structure is not complicated.  Start by invoking “createShape,” and then use the “beginShape” method.  Adding vertices to a shape involves using the “vertex” method, once for each vertex.  This seems a bit cumbersome to me; I am new to using shapes in Processing, so I’m hoping to learn more.  I had been able to get by with just creating points, lines, rectangles, and circles so far — but that doesn’t give students as much room to be creative as including arbitrary shapes does.

I should point out that shapes can have subshapes (children) and other various attributes.  There is also a “fill” method for shapes, but I have students use the fill function call in the for loop to avoid having too many arguments to myshape.  I also think it helps in understanding the logical structure of Processing — the order in which functions calls are invoked matters.  So you first set your fill color, then when you specify the vertices of your polygon, the most recently defined fill color is used.  That subtlety would get lost if I absorbed the fill into the myshape function.

As in previous semesters, I’ll let you know how it goes!  Like last semester, I’ll give updates approximately monthly, since the content was specified in detail in the first semester of the course (see Section L. of 100 Posts! for a complete listing of posts about the Mathematics and Digital Art course).

Throughout the semester, I’ll be continuously moving code from Sage to Processing.  It might not always warrant a post, but if I come across something interesting, I’ll certainly let you know!