Wednesday 5 November 2008

Anti-aliasing in Processing

Over the last few days, I have started to play with Processing, primarily to get a feel for its capabilities.

On the whole, I am impressed by the simplicity. It took me less than a minute to produce some (albeit simple) graphics. The lack of the normal "clutter" associated with most programming languages is a big plus for those that just want to produce images.

What I am less impressed with are some of the idiosyncrasies. Two in particular revolve around the functions loop()/noLoop(), and smooth()/noSmooth().

The loop()/noLoop() functions control whether draw() should be called once, or continually. By default, Processing is set to loop(). This is fine for animated graphics, and applications with some user interaction (such as through keyboard or mouse events), but for simple static graphics it has two downsides.

The first is on machine performance. A quick look at a performance meter shows that the continual redrawing has its cost. For simple applications, this may hardly be noticeable, but an application that involves any disk access (e.g. image reading) or complicated calculations is likely to noticeably impact machine performance. It is therefore important to keep any operations that only need to be performed once in the setup() function.

The second downside is image quality, and this is where the smooth()/noSmooth() functions come in. The smooth()/noSmooth() functions control anti-aliasing. This is important in computer graphics. We have moved on from the primitive computer graphics of the early 1980s home computers such as the Sinclair ZX Spectrum, and yet the default in Processing is set to have the anti-aliasing switched off with an implied call to noSmooth().

To me, the default settings for these two functions are wrong. Anybody new to Processing is going to start with simple, static images. They will be looking at issues like ease of use, and image quality. Surely it would be better to default to noLoop() and smooth(), rather than loop() and noSmooth() as is currently the case?

This isn't just an academic argument either. As I will show below, these settings have a very visible effect of results.

Consider the following code. The intent is to draw a black circle on a white background:
void setup(){
size(140, 140);

background(255); // White
stroke(0); // Black

strokeWeight(10);
ellipseMode(CENTER);

smooth() or noSmooth();
loop() or noLoop();
}

void draw(){
ellipse(70, 70, 120, 120);
}
It will be noted that this code is not entirely syntactically correct. The smooth() or noSmooth() and loop() or noLoop() lines give 4 variations. The table below shows the result of these variations:



noSmooth()smooth()
noLoop()
Suggested default settings
loop()
Default settings

The visual differences in image quality are obvious. A check sum compare of both of the unsmoothed images shows that they are byte-for-byte identical. The same is not true for the smoothed images.

I don't understand why the developers of Processing choose these defaults, and nor do I understand why the smoothed image quality is reduced when looping, unless there is some deliberate throttling of the algorithm to reduce processor overhead.

So, to recap, if you are drawing static images, I recommend the following skeleton code:
void setup(){
size(x, y);
smooth();
noLoop();
}

void draw(){
}

Wednesday 29 October 2008

Introducing polynomials

Below is my first draft of my section introduction. Hopefully it introduces polynomials from a perspective that everyone can understand. I welcome any comments from my fellow authors.
Polynomials

We have previously, on page XX (fragment 24), introduced some basic algebra and straight line graph plotting. In this section we will introduce some simple mathematical curves, and in doing so, show that all numbers may be represented by a point on a given curve or curves.

We will start by looking at some every day numbers, and show how they can be represented by algebraic notation. If you are already familiar with such concepts, you may wish to skip this section.

From numbers to algebra

We all use numbers in our daily lives. Some examples of numbers we use are:
Height1.54m
Weight53kg
Price£4.99
Answer to life, the universe, and everything42
Attendance at a sporting fixture21,988
The units of measurement are unimportant for this exercise.
Most of the time we give very little thought as to what these numbers mean from a mathematical perspective.

What does a number like 21,988 actually mean?

Firstly, we know that it is a count of the number of people who attended a sporting fixture. Counting is one of the first skills we learn, often using our fingers. It is no coincidence that our counting system revolves around the number of fingers, or digits, that we have. A count of something is a one-to-one correspondence between the number and the physical thing.

We can break 21,988 down into its constituent parts:
21,988 = 20,000 + 1,000 + 900 + 80 + 8
We call each of the numbers being added together in this equation terms.

We can break each term down a little further:
21,988 = (2 × 10,000) + (1 × 1,000) + (9 × 100) + (8 × 10) + (8 × 1)
The brackets, or parenthesis, around the 2 × 10,000 means "do this calculation first".

100 is 10 × 10, or 10 squared. We can also write this as 102. Likewise, 1,000 is 10 × 10 × 10, or 10 cubed. We can also write this as 103. We call these powers of 10. For consistency, we can extend this logic to all other powers of 10, although, some may not be obvious, for instance 101 is 10, and 100 is 1.

We can now rewrite our breakdown of 21,988:
21,988 = (2 × 104) + (1 × 103) + (9 × 102) + (8 × 101) + (8 × 100)
This example is very specific to the number 21,988. What if we want to write a generic formula for any number?

Firstly, we can replace all instances of 10 with x, and 21,988, with y:
y = (2 × x4) + (1 × x3) + (9 × x2) + (8 × x1) + (8 × x0)
We now need to replace the digits 2, 1, 9, 8 and 8. We will replace them with an a, but as they are all different, we need to distinguish between them. We can do this by using a sub-scripted number, which for clarity, will be the same as the power of x. We call these coefficients, and we call the number attached to the coefficient an index:
y = (a4 × x4) + (a3 × x3) + (a2 × x2) + (a1 × x1) + (a0 × x0)
We can tidy this equation up a bit. We stated above that 101 is 10, and 100 is 1. We can be more generic and state that x1 is x, and x0 is 1. This simplifies the last two terms of the equation to:
(a1 × x) + a0
We can also remove the ×, by either using a . in its place (i.e. a1.x), or, as we will do here, just implying multiplication. Because multiplication has a higher precedence than addition, we can also remove the parenthesis. Applying this to the entire equation then gives:
y = a4x4 + a3x3 + a2x2 + a1x + a0
This is fine, for a number of 5 digits or less (i.e. a4 = 0 cancels out x4, and hence will give a 4 digit number), but what about numbers consisting of an arbitrary number of digits? We can replace the index number of most significant term with n, and the index number of the next most significant term with n-1:
y = anxn + an-1xn-1 + … + a2x2 + a1x + a0
We call this type of equation, a polynomial, where poly means many, and nomial means term.

We call the most significant index the degree of the polynomial. In the last equation, the degree is n, and in the 21,988 example, the degree is 4.

It will be noted, that because our least significant index number is 0 (that is we count from 0 and not 1), n will always be 1 less than the maximum number of digits in the number.

We now have an abstract representation of any number.

To bring all of this full-circle, if we set x to 10, a4 to 2, a3 to 1, a2 to 9, a1 to 8 and a0 to 8, we get:
y = (2 × 104) + 103 + (9 × 102) + (8 × 10) + 8
In our 21,988 example, x was always 10. This does not always have to be the case. On page XX (fragment 77), when we introduce bits, we will be dealing with powers of 2 and 16.

We shall now look at a number of different polynomial equations, by plotting the resultant value of y for various values of x.

Tuesday 28 October 2008

Formatting of code fragments on blogs

I have just left a comment on Darrel's blog regarding formating of code fragments within a blog. Unfortuantly, the blog commenting facility doesn't allow use of the HTML pre tag, and hence the point I was trying to make was somewhat lost! For clarity, I repeat it here.

Use of the HTML pre tag leaves white space intact, allows direct use of > and <, and uses a courier font. E.g.:
setup(){
int x = 0;
if (x > 0){
doSomething();
}
}

Notation, notation, notation

Upon re-reading my last post, it occurred to me that the notation chosen was likely to be confusing.

To illustrate, we will take the 4 equations previously stated, and line up all of the terms:
Constanty = a
Lineary = ax + b
Quadraticy = ax2 + bx + c
Cubicy = ax3 + bx2 + cx + d
It will be noted that the name of equivalent coefficients changes in each equation.

If we were to use a generic form for the equation, then this name changing goes away:
y = anxn + an-1xn-1 + ... + a3x3 + a2x2 + a1x + a0
Whilst this looks more complex, if we just concentrate on equations of the cubic order and lower, we get:
y = a3x3 + a2x2 + a1x + a0
If a3 is 0, then we get a quadratic equation, and so on:
y = a2x2 + a1x + a0
I think this is potentially less confusing than having the coefficient names change with each order of equation. It also provides for a cleaner and clearer mapping between the underlying mathematics and Java arrays, if we were to chose that mechanism to store the coefficients.

Monday 27 October 2008

Initial thoughts

Most of the chunks that touch on mathematical subjects are going to be challenging to write. Our task is to write a book that demonstrates how the various facilities in the Processing language can be used to create pictures. Out task is not to teach mathematics. That said, it is difficult to use the various facilities effectively if one does not have some basic knowledge as to the underlying theory. Getting this balance right is potentially one of the biggest challenges we will face.

Obviously I need to start with what a polynomial is, and what they look like, in terms of their generic form. I'd like to use the old joke that a polynomial is a hungry parrot, but I suspect that's a bit too Pythonesque for most people!

Being restricted to quadratic and cubic equations simplifies the task slightly. I can see these equations being a little scary to some:
  • y = ax2 + bx + c (quadratic)
  • y = ax3 + bx2 + cx + d (cubic)
I will probably start off with constants and straight lines, and build up from there:
  • y = a (constant)
  • y = ax + b (linear)
Apart from showing the effects of altering the various coefficients (a, b, c and d), and a very brief explanation of power notation, I can see little to be gained by going into the maths any further.

I would like, where ever possible, to highlight real world examples of these curves. For example, the parabola, as described by a quadratic equation, is formed as the result of a conic section, and is also used for reflectors with a focal-point, such as satellite dishes and light reflectors.

Whilst waiting for my book to arrive, I will do some background reading.

Following other mass writing blogs

I've noticed that other authors are already following this blog. So far, I am only following the 3 blogs created by Darrel. Trying to follow 85 blogs is likely to be virtually impossible. I will therefore only follow those blogs written by authors whose subject matter is a prerequisite for my chuck. I hope that the other authors won't be upset by this decision.

Polynomials

I sent an e-mail to Darrel earlier today listing my 3 preferred chunks to write. I got my third choice, which is fine. So, my brief is:
CHUNK 55
TITLE Polynomials
DESCRIPTION Describe the general form of quadratic and cubic polynomials and show how they can be drawn using the techniques in Greenberg 262--267. Describe a simple program that shows the various curves that are generated by such polynomials
OUTCOME
  • Describe the general form of a polynomial
  • Develop code that draws a particular polynomial.
REFERENCE Greenberg 262-267
HINT Keep the programs simple.
PROGRAM No program required.