Computers and Chaos - (Amiga ed)

For hundreds of years scientists had disregarded the intricacies of the non-cyclic, erratic side of nature, believing it to be too difficult to predict and managing instead with generalised behaviour patterns. With the birth of chaos theory it seemed as if a solution to these fundamental problems may at last be in sight. Surely if the cause of unpredictability could be found it would be possible to cure it. Some chaos crusaders even rated it as the third great physics discovery of the 20th century, after quantum mechanics and the theory of relativity.

The backbone of chaos theory is the notion that complex behaviour does not have to come from complex rules, thus inferring that a system as complicated as the weather may be summed up in one simple equation. The hope is that chaos will be able to give us an equation for everything. This does, however, seem far from likely at the present time as the science is still in its infancy. What a lot of people fail to understand is why it has taken so long for scientists to acknowledge the importance of chaos. Surely if it is so fundamental it could have been appreciated centuries ago.

The catalyst for the research has undoubtedly been the computer. The millions of calculations that must be performed in even the simplest of chaotic processes make manual calculation practically impossible. In the beginning it was only well-funded defence establishments and universities that could afford the equipment necessary to carry out such experiments. But since the early 80s the price and size of computers have fallen dramatically, while power and availability have increased, bringing chaos within easy reach of many other people. Never before have so many people been able to become actively involved in such a state-of-the-art science, and this has been a major factor in its increasing popularity.

Many books have been written on the subject at all levels and mathematical periodicals, not normally touched with a barge-pole if possible, strangely went missing from reference libraries across the world. This incredible level of interest has grown ever since, with some chaos books becoming instant best-sellers, and less than five years after the discovery of the Mandelbrot set, popular computing magazines were publishing polished programs to display it on home computers.

Fractals are abstract shapes existing in two or more dimensions, whose incredible complexity prevents them from being treated like normal geometrical shapes. Fractals have surprisingly little ordered structure, despite the fact that they originate from very simple rules. Such images have been irreversibly linked to chaos theory because they are such a good example of how immensely complicated output can be created from a very simple process.

The typical example of a computer generated fractal is the Mandelbrot set, whose infinitely complex structure is uncharacteristic of the simple equation from which it originates. Like most things in chaos theory these computer images are not abstract from the real world, frost on a window and the structure of a tree are natural fractals. Fractals don’t always have to be static though. For example, a November 5th sparkler produces a constantly changing fractal structure of sparks.

This is a very generalised definition of a fractal, and a more complete one will be built up as the book progresses. Fractals are most successfully described with the aid of practical experiments and examples, such as those provided for the Amiga in later chapters.

In terms of power, price and software availability the Amiga is undoubtedly one of the best value computers around, now rivalling the less powerful Atari ST. The Amiga is particularly suitable for fractal work because it can perform the necessary calculations very quickly and the output can be displayed in up to 4096 colours, or up to a resolution of 640x512 pixels. The inclusion of the mouse, printer port and disk drive mean that chaos programs can be made very user-friendly, with easy storage for the final output.

The only problem with the Amiga is the language supplied with it, Amiga BASIC, lacks some features (e.g. recursion) which are essential for fractal work. However, because Amiga BASIC is readily available, easy to read and not unworkably slow it has been used for most of the examples in this book. In fact a listing can be assumed to be written in Amiga BASIC unless otherwise stated.

The decision regarding the best language on which to base other parts of the book was a more difficult one. Machine code was ruled out immediately because of its unstructured, often difficult to understand nature. The C language is widely used by chaos researchers due to its speed, mathematical capabilities and structure. However, versions of C for the Amiga generally cost about five times more than comparable BASICs, meaning that few Amiga owners have had a chance to become familiar with them. The only other well supported high-level language for the Amiga is BASIC, so the choice was narrowed down to the four main Amiga versions of the language, shown in Table 1.1.

Due to its pricing and popularity GFA BASIC appeared to be the most suitable choice. Hisoft BASIC would also have been a good choice, but even though it is compiled it is still slower than interpreted GFA BASIC. AMOS and Blitz BASIC were not considered as they are geared more towards games than mathematical applications. Appendix C gives advice on converting the GFA BASIC and Amiga BASIC example programs to other dialogues of BASIC and to C.

In the GFA BASIC programs only version 3.0 syntax has been used, so the programs should work on both version 3.0 and 3.5 of the language without alteration. If you have the GFA compiler it is recommended that you use it once you are sure that the program has been typed in correctly (i.e. when it works with the interpreter). Note that the GFA BASIC compiler only gives a very slight increase in speed over the interpreted programs.

Chaos theory can appear daunting, but the use of simple programming procedures and notational conventions in this book should make it very accessible. The following few pages provide details of the conventions used and give other hints to help you get the most out of both the text and the listings.

Because it was discovered by mathematicians in the early 1900s, the Sierpiński triangle is one of the oldest fractals covered in this book. The reason for the triangle’s relatively early discovery is that it is based on very simple rules and can be drawn by hand, with little or no calculation. This meant that its creators were not hindered by their lack of computational machinery, the like of which is now indispensable in chaos research. Although the Sierpiński triangle can be drawn by hand it does take a considerable amount of time, so to demonstrate it here we will be using the Amiga. However, if you would like to follow the original method you are quite welcome!

The starting point for the triangle is a blank plane, on which a triangle is outlined by three single points, numbered 0, 1 and 2 for reference. Such a situation is shown in Figure 2.1. The Sierpiński triangle can now be created on this plane by applying the following rules:

This type of process is known as an iterative process, because a single set of rules is applied repeatedly in order to produce the result. Each application of the rules is called an iteration, in our example the plotting of one pixel represents one iteration. Figures 2.2a to 2.2d show the evolution of the triangle after different numbers of iterations.

It is quite natural to expect this random process to yield a random result but, as Figure 2.2 shows, the process eventually gives rise to a rather complex, ordered structure - the Sierpiński triangle. This unusual behaviour is best demonstrated with the aid of a simple program which executes the rules given above. Such a program is shown in Listing 2.1.

Basically it can be broken down into three sections. The first dimensions two arrays to store the horizontal (x) and vertical (y) positions of each of the three vertices of the triangle, and places suitable values in them. The next section corresponds to stage one of the above process, as it initialises the drawing position by randomly setting it to be at one of three vertices. The drawing position can be thought of as the position of the computers 'pen' to give consistency with the manual drawing method. The drawing position is held in the variables <F102>px<F> and <F102>py<F>. The final section of the program is the WHILE…​WEND loop which actually does the drawing of the points, representing stages two and three of the process.

The only relatively difficult area in this program is the part which moves the graphics cursor halfway towards a vertex. This is done by finding the mid-point of the imaginary line between the current position and the relevant vertex, and moving to it. The method of finding the mid-point of the line has been borrowed from co-ordinate geometry, which states that if there are two points with co-ordinates (x,y) and (x1,y1) respectively, the mid point of the line between them is at (x+(x1-x)/2,y+(y2-y)/2). More details on graphs and the (x,y) notation can be found in Appendix B.

When typing in Listing 2.1 you should ensure that you follow the guide-lines given in Chapter 1. However, as this is the first program in the book, explicit instructions will be given here to help you get the triangle up and running.

First you should load Amiga BASIC as normal and ensure that there are no BASIC programs in memory. Listing 1.1 should then be typed in exactly as shown (remarks may be omitted if desired). Assuming you have corrected any syntax errors you may have made the program can now be executed by clicking with the mouse on the start option of the run menu, or by simultaneously pressing the right Amiga key and <R>. If you have typed in the program correctly you will see the triangle gradually appear, filling most of the screen.

Physicists and mathematicians are lucky. The problems they have to solve are generally based on inanimate objects which can usually be studied, or at least modelled, in a controlled laboratory experiment or on paper. Biologists, on the other hand, often have to study in a much larger laboratory of the Earth, where their experiments are constantly at risk from natural sabotage. The complex interactions between living organisms and their surroundings make it impossible to enact biological studies in the lab without upsetting the results, which means that patterns and predictions are very difficult to establish.

However, to make their lives somewhat easier biologists have developed a branch of their science called ecology, in which individual creatures and events are generalised to produce simple mathematical equations which can predict the behaviour of large groups of organisms over a period of time. One such equation, used to predict simple population changes, is the May equation, developed in 1845 by Verhulst but much studied by the 'mathematical biologist', Robert May. It is this equation which forms the basis of the Feigenbaum diagram, named after Mitchell Feigenbaum, the first person to draw the whole diagram and analyse it in detail.

The Feigenbaum diagram represents the opposite situation to that of the Sierpiński triangle. That is to say the complex, and in some places chaotic structure (see Figure 2.10) is generated from the very simple, non-random formula which May derived from population dynamics. The accepted name for a non-random process such as this is a deterministic process.

An example derivation of the equation can be obtained by considering the spread of a virus through a group of people. A virus has been used for the demonstration because viruses are among the simplest living organisms. In this case the population is defined as the number of people infected by the virus at any one time, and we are trying to find a method of predicting it at any stage in the future.

The accepted method of deriving a formula is to start from a very basic equation and then elaborate on each part of it in turn using other equations and basic facts. The equation we shall use as a starting point is shown below. It allows us to calculate the number of infected people at the end of any one week. The equation basically states that the number of people infected at the end of the current week (pnew) is equal to the number of people infected at the end of the previous week (p) plus the number of people who have been infected since then (n).

p_new=p+n

This equation is technically correct, but to calculate the population for any given week it is necessary to know the number of people infected during that week. This means that the equation can only be used to work out populations of weeks gone by, and cannot predict the future.

However, the need to know the number of newly infected people (n) can be eliminated because it can be shown that n is directly proportional to the number of people already infected at the end of the previous week (p). This is due to that fact that as the number of people infected increases so does the likelihood of an uninfected person coming into contact with an infected one, which in turn increases the chances of the healthy person being infected.

n α p

Of course, infected people cannot be re-infected so, assuming that all unwell people are contagious, the number of newly infected people must also be proportional to the number of healthy people. If, for example, everyone in the group was infected nobody else would be able to become infected, so n would be zero. Assuming that there are no in-betweens the number of healthy people must be equal to the total number of people in the group less the ones who are infected.

To eliminate the need to know the actual number of people in the group (and to show that this is unimportant to the equation) we can use percentages instead. In mathematics the numbers from 0 to 1 inclusive are generally used to represent percentages from 0% to 100%, where 0.5 is 50% for example (Appendix B gives more details on this and other pure maths topics). From now on we shall assume that p and pnew represent the percentage of the group infected at different times, and that n represents the percentage of the group who become infected during the week. The percentage of healthy people in the group is therefore 100%-p, as shown in Figure 2.5.

This can be represented mathematically as (1-p), remembering that 1 represents 100%:

n α (1-p)

Because n is directly proportional to both p and (1-p) we can say that n is proportional to p*(1-p). An equation combining these facts is:

n=p*(1-p)

You may be able to guess that if this definition of n were substituted into the equation for p shown above, p would steadily rise to 100% and then stay there. If this were the case in the real world, and the group of people were the earth’s population then the existence of the human race would be in doubt. In reality, however, certain people may not meet as many people as others, and a meeting does not mean definite infection. Also people may recover from the virus, either using the body’s immune system, or with the aid of medical treatment (depending on the nature of the virus). For this reason a constant, c, must be included in the equation. This represents the success rate at which the virus spreads and persists in the human body, and will hereafter be referred to as the contamination constant.

Because n is proportional to c we now have the following definition of n:

n=c*p*(1-p)

The result of substituting this definition into the equation for p is the May equation:

p_new=p+c*p*(1-p)

The beauty of this equation is its universality. As already discussed the use of percentages makes it independent of the number of people in the group. Since the number of people in any particular group is certain to change, due to births and deaths, this is of fundamental importance.

The introduction of the constant, c, also makes the equation more versatile by allowing it to be customised for any combination of virus and host. This means that the hosts do not have to be people, they could just as easily be animals or even computer disks! For a different virus/host combination a different value of c is all that is required.

In this chapter it has been shown, using the Feigenbaum diagram, that a simple mathematical equation, with no random elements can give rise to what appears to be a totally random result, and that a random set of rules can give rise to a pattern of very rich structure, such as the Sierpiński triangle.

This two way relationship between order and chaos is more than anecdotal, it represents a whole new way of perceiving natural processes occurring around us. For although our simple virus population program has inaccuracies it still illustrates the important point that a natural process such as population growth and decline can be described in one simple equation with nothing more than some common sense and a little help from the laws of statistics. Is it possible, then, that even the most complex natural processes can be reduced to simple equations, thus allowing them to be predicted with relative ease? This important question is dealt with in the next chapter.

The is no doubt that Lorenz’s carefully planned experimental models were very enlightening, but probably his most important discovery was accidental. Wishing to hurriedly continue an earlier run of his model Lorenz used initial values of x, y and z taken from an earlier printout. He assumed the fact that the values on the printout were rounded off to three decimal places (from his computer’s more accurate internal values) to save space would not make much difference to his readings.

To simulate the original run of the model we can alter the relevant lines in Listing 3.1 so that the initial values of x, y and z are set up as follows (it is important to type the numbers in full):

These numbers are of the same precision as those used internally in the program by Amiga BASIC, and are said to be shown to 16 significant figures. If the program is now executed (with the detail variable set to 5) a graph similar to that shown in Figure 3.4a will be produced, which is not particularly unusual. However, if the program is executed with the initial values rounded off to four significant figures completely different results can be seen.

The initial values can be rounded off by changing the relevant lines to read as follows:

Rounding these numbers off is effectively what Lorenz did by typing in the old printed out values. The output from these less precise initial conditions is shown in Figure 3.4b.

Comparing the two lines reveals that although they follow the same path for the first few iterations they gradually diverge into totally different patterns. Figure 3.4c illustrates this more concisely by super-imposing the two lines on the same graph. The effect witnessed here is what is technically known as sensitive dependence on initial conditions, meaning that the equations are so sensitive to the initial conditions supplied to them that even the smallest difference in the initial values quickly grows into a large difference.

Lorenz immediately realised what his results meant. They showed that his model, and hence the weather, had a sensitive dependence on initial conditions. Ultimately this meant that weather prediction was practically impossible, because even the smallest error from a thermometer or other instrument would send a forecaster’s model off down an increasingly wrong track. Other meteorologists took a more optimistic view, believing that they could alter future weather by making the relevant small changes such as heating small areas of land.

They were of course right, but Lorenz pointed out they could not control the weather with any precision, as the effects of the small changes they made would be impossible to predict because other, undetected, small changes would have equally large results. Some argued that a complex system such as the weather was so sensitive that the path of a hurricane could be reversed by a butterfly taking off from the other side of the globe. Hence the name 'butterfly effect' was coined as the common term for sensitive dependence on initial condition.

A more down-to-earth example of the butterfly effect is the story of an airline company going bankrupt. A man leaves his house on foot one morning, with the purpose of going to the travel agents to book his holiday. After walking a few yards down the street he looks down and finds that his shoelace has come undone. Naturally he bends down to tie the lace, but in doing so he loses his balance and falls into the road. As he stumbles to his feet a passing bus collides with him and he is subsequently taken to the local hospital. Because of this the man is unable to book his flight before the deadline, meaning that the airline company is one person short of the quota needed to make the flight financially viable. The flight is cancelled, and ticket holders refunded, but with the absence of the income from that flight the already troubled airline company gets into financial difficulties and goes bankrupt. It seems incredible, you never read of companies going bankrupt because of undone shoelaces, but it could happen, and it would be almost impossible to predict.

As the airline example shows, weather is not the only thing that would suffer because of the butterfly effect, world money markets, politics and the lives of individuals can be drastically affected by even the smallest changes. The airline discussed above could have been a major company, and its downfall could have pushed an already gloomy economy below a critical level and toppled the government and lead to civil war.

The butterfly effect raises important questions about the wisdom of organisations around the world who expend considerable resources on weather prediction. However, in the short term the errors are small, so forecasting a day or two in advance is just about possible with a fast computer, accurate algorithms and a bit of luck, but past that predicting the weather becomes more of an art that a precise science.

At first it seems strange that something as simple as the Lorenz model is so unpredictable, when more complex periodic systems such as the ebb and flow of the tides, and planetary motions are so easy to forecast. The reason that periodic systems are much easier to predict is that their repetitions are easy to observe and describe mathematically. Almost all non-linear dynamic systems (including the Lorenz model) are non-periodic, meaning that they are prone to the butterfly effect, and hence unpredictability and chaos.

The Lorenz model has three variables, three directions in which it can change, and is therefore said to be three dimensional. This means that instead of simply plotting a time series graph of z against time we could plot x against y against z on three dimensional axes, like those shown in Figure 3.5.

The shape produced is known as the Lorenz attractor, an infinitely long complex spiral which never intersects itself. Plotting it in all three dimensions is rather involved and unnecessary, as a good representation can be achieved by plotting z against x in two dimensions.

Figure 3.6 shows the graph that results from this process, but to fully appreciate the line’s behaviour it is necessary to see it being drawn. Listing 3.2 can be used for this purpose.

The Lorenz attractor takes its name from the mathematical definition of such an object. An attractor is a set of points, in an imaginary mathematical space known as phase space. Each point on the attractor represents the state of the system at a particular time, and the line showing the sequence of these points is known as the trajectory. By looking at the trajectory of the attractor the behaviour of the system can be determined. The idea of attractors has been around for some time, but non-periodic attractors (called strange attractors) such as the one created from the Lorenz model are relatively new.

As this program shows, the trajectory behaves unpredictably, switching from lobe to lobe almost at random, but it does produce a very complex structure. One of the curiosities of the line is that it never intersects itself, although on the two dimensional screen of the computer it looks like it does. Because the Lorenz attractor is non-periodic it cannot intersect itself, if it did it would rejoin an old trajectory and periodically repeat. However, if the line never crosses and goes on forever it must be true that an infinitely long line can exist in a finite three dimensional space. As with many chaos ideas this obviously contradicts the laws of physics, but in fact it is possible if the space in which the line is enclosed is what is known as folding space (see the books listed in the Bibliography for details).

The Lorenz attractor is similar to many natural systems which exist in real space. For instance the turbulence in a fluid and the trajectory of an object orbiting a two planet system have similar properties. A recently developed executive toy, consisting of a metal pendulum oscillating over a bed of magnets, also exhibits similar behaviour.

The butterfly effect raises an interesting question: what is the real Lorenz attractor? Lorenz drew his first diagrams using output from a program using numbers correct to six decimal places. The Amiga BASIC variables which we used had a precision of 15 decimal places, so our program will produce a different output to that achieved by Lorenz. So who is right? This is a good question, but although the values may differ the general characteristics are the same.

Using three non-linear differential equations derived from chemistry it is possible to draw another strange attractor, the Rössler attractor. This exhibits all the same features as the Lorenz attractor, but is a different shape (see Figure 3.7). The equations are as follows:

dx/dt = -(y + z)

dy/dt = x + y * a

dz/dt = b + z * (x-c)

Listing 3.3 can be used to draw the attractor. Note that in most respects it is the same as the Lorenz program (Listing 3.2), except that the three equations are different and a pseudo-3D effect is created by plotting y+2*z (instead of just z) against x.

Again the constants and initial variables can be altered to produce a different Rössler attractor.

It has been mentioned in this chapter that the trajectory of a strange attractor never intersects itself. This is obviously true because the systems on which strange attractors are based are non-periodic (non-repeating), and for the trajectory to go through the same point twice would obviously be a repetition. Because the attractors are three dimensional but the Amiga’s screen is only two dimensional it often looks as though intersections are occurring, where lines are actually passing behind or in front of one another.

The simplest way of verifying the non-periodic nature of the attractor is to use colour to represent the third dimension. If each point was plotted in a colour proportional to the value of y in the program given in Listing 3.2 then, ideally, two adjacent pixels would be touching only if they were both of the same colour. However, the range of values for y is considerably larger than the range of colours on the Amiga making this method unusable.

An alternative, and very impressive, way of getting round this problem is to write a program to produce an isometric 3D attractor which rotates around the z axis. The rotation gives the impression that the attractor is truly three dimensional, and just by watching it spin it can be seen that the line doesn’t cross. Such a program is beyond the scope of this book, but a less ambitious one allowing static 3D versions of the attractor to be drawn at any angle of rotation would allow the same observations to be made. Three dimensional drawing methods are introduced in Chapter 7.

There are many more strange attractors which are just as interesting as those discussed here. Information on other attractors can be found in some of the books listed in the bibliography near the end of this book.

Like the strange attractors discussed in the previous chapter the Mandelbrot set is based on a deterministic non-linear process, but whereas the results of the Lorenz and Rössler equations are drawn directly onto the screen as a graph the relationship between the Mandelbrot equation and the resulting set is more complicated.

The first part of the process takes place in a circle such as that shown in Figure 4.1, with centre (0,0) and radius 2. Inside this circle there is a single point, at an initial position (a,b), to which the following non-linear equations can be applied (for details of indices and the ^ notation see Appendix B):

p~new = p^2 - q^2 + a

q_new = 2*p*q + b

In BASIC this is most suitably written:

pnew = p*p - q*q + a

qnew = 2*p*q + b

Figure 4.2 helps to explain further these two equations by showing the feedback that occurs between them on successive iterations.

So far we have only specified that a is the initial horizontal position of the point and b is the initial vertical position. No mention has been made of _ p_, p_new, q or q_new. Naturally these four variables will be subject to change as the equation is applied, and the values of _ P_new_ and q_new will automatically be worked out because they are the results of the equation. That still leaves p and q unaccounted for, and although these will inherit values from p_new and q_new during subsequent applications of the formula they require some initial values to get the process started. For the time being we shall say that p and q are both set to 0 before the process is invoked, so that the first position calculated is the initial position, (a,b).

Now that we have our set of initial values, and the full equation, we can perform a 'dry run' of the process for one point, as shown below. In this example our starting point will be (-1,0.5), i.e. a=-1, b=0.5.

Initially: a = -1 b=0.5 p=0 q=0

Application of the equation gives:

p_new = _p*p - q*q + a q~new = 2*p*q + b

So the first position is (a,b) as expected.

p now becomes the latest value of p_new, and q becomes q_new, this can be represented as:

<$table4>p = p_new (= -1) q = q_new (= 0.5)

The equation can now be re-applied…​

p_new = p*p - q*q + a q_new = 2*p*q + b

p = p_new q = q_new

…​and re-applied…​

p_new = p*p - q*q + a q_new = 2*p*q + b

p = p_new q = q_new

Only three iterations have been performed here to save space, but had more iterations been performed the results in Table 4.1 would have been observed.

etc…​

These results are reminiscent of those produced by the virus equation in Chapter 2, in that they are very complex, and appear to be almost random. Of course the results are not random as they come from a deterministic process, which if repeated will yield the same values.

Returning to the wider situation we can now plot the path of the point in the circle, which results in the image shown in Figure 4.3. This output can easily be achieved on the Amiga by calculating the values of p and q (hence the position of the point) for successive iterations, and then drawing straight lines between these positions. A program to do this is shown in Listing 4.1. Note that the iteration count is displayed in the top left of the output window to give an impression of just how many calculations are taking place.

The program automatically stops if the line breaches the circle, but can also be halted by hitting the right Amiga key and the period (.) key simultaneously. Checking whether the point is outside the circle is done mathematically, using the technique shown in Figure 4.4.

The diagram shows that if (p,q) and (0,0) are taken as being two corners of a right angled triangle, the distance between these two corners is equal to the length of the triangle’s longest side, the hypotenuse. The length of the hypotenuse (r) can be calculated from the length of the other two sides using Pythagorus' theorem, the formula for which is shown below.

r^2=p2+q^2

If the point (p,q) is inside the circle it is impossible for the hypotenuse to be greater than 2, so:

r⇐2

squaring both sides gives:

r^2⇐4

and after substitution into the Pythagorus equation:

p²+q²⇐4

It is this final form of the equation which is used in the WHILE line to check whether the program should end. Appendix B provides a more detailed description of Pythagorus' theorem.

Because the range of values for p and q is so small the plotting co-ordinates must be significantly amplified in order to make full use of the screen. This is done, as usual, in the PSET and LINE lines. Also familiar is the reversal of the q position, required because the Amiga’s screen co-ordinates are numbered from top to bottom rather than in the conventional bottom to top way (see the graphs section of Appendix B for details).

From Figure 4.3 it can be seen that the route which the point takes is not especially structured. This is true of most paths plotted by the program, but sometimes patterns do seem to emerge, for example the pentagram in Figure 4.5a which is the path of the point with initial position (-0.52,-0.55).

This is all very interesting, and you may want to spend some time experimenting with various initial positions of the point, but how does this relate to the Mandelbrot set? Well, each set of initial values (a and b) can be put into one of two separate categories depending on the path of the corresponding point, generated by applying the Mandelbrot equation. The two categories of points are:

It would obviously take an infinite amount of time to thoroughly test a point in order to determine whether it flies off to infinity or not, but it can be shown that if the point breaches the boundary of the radius two circle it will eventually reach infinity. Using this reasoning we can say that the initial point (-1.5,0.5) demonstrated above is an example of a category one point. An example of a category two point is (0.35,0.35), whose path is shown in Figure 4.5b.

This was tested using the program above, and had still not exited the circle after 20,000 iterations. Unfortunately there is no simple way to prove that a line will not reach infinity, so the brute force method of applying the equation many times must be used. The point at which we terminate the program and assume the point will never leave the circle is arbitrary, but iteration ceilings of 32 are generally typical (details of how to determine this number are given later).

To underline the behaviour of the equation Figure 4.5c shows another type one line, this time produced from the initial point (0.3505, 0.35). It is interesting to note that just the small change (a is 0.0005 units larger than in Figure 4.5b) produces an eminently different result. Such sensitivity to small changes in the initial conditions is typical of non-linear systems, as discussed in the previous chapter.

The categorisation of points according to their behaviour in the circle is the key to creating the Mandelbrot set. What we do is to take every point on another plane, where -2⇐p⇐2 and -2⇐q⇐2, put them through the equation and then categorise them. If all the type two points are coloured black and all others are left white we get the image shown in Figure 4.6, commonly known as the Mandelbrot set.

Figure 4.7 has been included to help visualise the process and shows the relationship between points of the Mandelbrot set and their associated circle planes. A program to produce a plot similar to the one shown in Figure 4.6 is given in Listing 4.2.

Note that not all the points on the 4x4 plane can be tested because, as on any plane, there are an infinite number, meaning that they would take an infinite amount of time to process and they would not fit on the screen. Instead we plot a small portion of regularly spaced samples, allowing a reasonable approximation of the Mandelbrot set to be built up. An approximation is the best that can be achieved because of the limitations imposed by the Amiga’s screen. The actual number of points calculated is determined by the distance between them. In Listing 4.2 this is the STEP size of the FOR…​NEXT loops. This distance is optimised here in order to give the maximum detail in the smallest amount of time, so naturally varies depending on what screen resolution is being used.

In simple terms we are running a simple, two dimensional, strange attractor with a series of different initial conditions. However, the ceiling of 32 iterations for each point means that mathematical feedback has a good chance to work without the problems introduced by the butterfly effect.

As mentioned in the first part of this chapter one of the Mandelbrot set’s most outstanding features is that such an intricate shape can be created from such simple rules. The circle and line method is not a particularly good way of showing this, as it is rather involved. By contrast the use of complex numbers can allow the Mandelbrot to be created from the single equation:

z_new = z^2 + c

This is a very simple equation with mathematical feedback, much like the virus population one described in Chapter 2. In plain English this equation states that z is equal to the previous value of z multiplied by itself, plus a constant, c. In BASIC the equation might be entered as:

z = z*z + c

If we repeatedly apply this to normal numbers such as z=0.5 and c=1 we find that z tends to zero or infinity in a very ordered fashion. However, if complex numbers are used more interesting results can be observed. Before proceeding further a basic understanding of complex numbers may be necessary for some readers.

The Mandelbrot set is an incomprehensibly complex object, so a single plot cannot possibly contain enough detail to show all the intricacies of the set. For this reason it is useful to be able to mathematically manipulate the set using the Amiga, something which can easily be done in Amiga BASIC.

Because it is difficult with colours alone to ensure that each contour around the Mandelbrot set a unique colour it would be useful to have another way of representing these contours. A popular method for doing this is to draw an isometric three dimensional Mandelbrot, known as a Mandelbrot landscape, where points are elevated from the plane by differing amounts depending on the ease with which they left the circle. Because isometric drawing is an essential element of this technique 3D Mandelbrots are discussed in the chapter on fractal landscapes (Chapter 7).

Contours can be added to Julia sets using the same methods used in the previous chapter for the Mandelbrot set, where the contours are created by colouring points depending on the ease with which they left the circle. To save you referring back to Chapter 4, the possible replacements for the IF…​END IF section of the program are as follows:

For 16 colours (low resolution only):

<$ob> COLOR iteration MOD 16 !Set colour <$ob> PSET(320+x*100,100-y*50) !Plot point

For monochrome contours (high or low resolution):

<$ob> IF iteration/2<>INT(iteration/2) THEN !If iteration umber is odd…​ <$ob> PSET(320+x*100,100-y*50) !…​plot the point <$ob> END IF

Like the Mandelbrot set, Julia sets can also be drawn as 3D landscapes (see Figure 5.4), or with internal structure.

<$hb>Derivation from the Complex Number Method

Again, the method is similar to that given for the Mandelbrot set. The equation shown below still holds but c is kept constant the whole time, rather than being different for each point on the complex plane.

znew = z^2 + c

Because c is constant the position of the point is determined by the initial value of z which, instead of always being zero (0+0i), is different for each point on the plane. The Julia set drawn is dependant on the complex constant, c, whose real and imaginary parts are equivalent to the circle method’s a and b variables respectively.

<$ha>A GFA BASIC Julia Set Explorer

In general I have attempted to write the programs for this book in as compact a form as possible. However, there are programs available which allow you to explore fractals with all the convenience offered by graphical user interfaces, disk filing operations and printout facilities. This type of program tends to be very long and hence is unsuitable for a book primarily written as an introduction to the theory of chaos. However, as an insight into how such programs are created, a Intuition-based example to generate and explore Julia sets is presented in this chapter. The program is written in GFA BASIC, as this is the more suited to this type of task than Amiga BASIC. This example will prove especially useful if you want to develop your own fractal exploration programs, based on processes given in this book or elsewhere.

The full Julia program is shown in Listing 5.2. This is provided mainly for educational purposes and to allow important techniques to be gleaned. Due to the length of this listing it would be irresponsible for me to recommend typing it in. If you are interested in seeing the program in operation I suggest you purchase the support disk instead as this contains the entire program.

Before actually tackling a project of this sort a clear set of objectives and a plan for developing the program must be devised. The objectives for the Julia program are that it should:

<$bullet>Be able to plot (quickly) any Julia set requested by the user

<$bullet>Allow zooming (of any magnification) into any section of the set

<$bullet>Give options for filing sets and sections to and from disk

<$bullet>Display parameters in a form compatible with other literature

<$bullet>Allow for the filing of such parameters for later use

<$bullet>Give the user the option to dump images to a printer

<$bullet>Be implemented in an intuitive graphical environment.

This list basically brings together the Julia set facilities discussed above and the features that would be expected from a commercial art package or word processor. One of the most important points here is the parameter saving option as this would allow (for example) a Julia landscape program to draw three dimensional versions of sets already plotted and saved in two dimensions.

The intuitive graphical environment mentioned in the list must be Intuition, as it is resident in the Amiga operating system and is well supported by GFA BASIC. The use of Intuition in the Julia program comprises a pull down menu bar, alert requesters, simple windowing and mouse input.

A discussion of the menu bar (given later) provides a more detailed breakdown of the options available because, in a program of this sort, all the options must be selected either directly or indirectly from the menu bar.

There is no escaping the fact that Julia set generators must perform many time-consuming calculations. For this reason a number of steps have been taken to ensure that the Julia program is as fast as possible. The most general is the application of structured programming techniques, including the use of local variables wherever possible. Unlike global variables, these are local to a particular procedure and are lost when that procedure ends, which means that at any time there are fewer variables for BASIC to keep track of than there would be if all the variables were global. Also, when dealing with whole numbers, integer variables have been employed instead of the floating point ones selected by default. Integer variables are signified by having their names suffixed by a per cent character (%) and are processed significantly faster than their floating point counterparts. Of course DEFINT could be used to declare variables as integers, but the suffix notation makes it possible to see instantly what type a particular variable is.

I have used comments and long procedure and variable names throughout the program to make it easier to understand but, when running under the interpreter, these will slow the program’s execution. Obviously the comments may be omitted, but shortening names can introduce errors if sufficient care is not taken. If you intend to compile the program the long names and comments will not matter because these are automatically stripped out when creating the executable file.

<$hb>The Menu Bar

Because each menu option is consecutively numbered it is imperative that all possible options are considered before incorporating the menu into a program. The conventional way of organising menu bars is for the file, or project menu to come first, followed by a series of program-specific menus. The file menu always contains file manipulation options, some of which may be program-specific, followed, after a blank line, by an option to quit the program. These conventions have been adhered to in the Julia program, for which the full menu structure is shown in Figure 5.5. The first program-specific menu is the picture menu, whose options are fairly self-explanatory. The colours menu is used to select which of the three methods will be used to display the set, so the three options are mutually exclusive. The action of each option is:

Mono: The set is drawn with monochrome contours (default) Set Only: Only members of the actual set are drawn, in black Colour: The set is drawn with colour contours.

A tick is placed next to the menu item representing the selected colouring method. To save accidental loss of pictures, a tick is also used in the file menu (next to the save option) to inform the user of whether or not the set in memory has been saved.

GFA BASIC stipulates that the menu structure must be stored in an array with each menu item in a separate element of the array, placed consecutively in the order in which they are to appear. An empty string ("") is used to mark the end of each menu, and a pair of empty strings mark the end of the last menu (the end of the menu structure). The information for the Julia menus is placed in an array called <F102>menu$<F> in the <F102>initialise<F> procedure (see Listing 5.2). This array could have been filled using more compact code, but by using the longhand method it is easy to determine how the menus are arranged and what number each menu item has, merely by glancing at the program.

A further array, called <F102>status%<F>, is used to store information about the status of menu items - whether they are disabled for example. This information must be stored in this way because the built-in GFA BASIC menu routines lose such information when the menu bar is switched off (as it frequently is in this program). The status of a menu item is set using a command of the form:

<$ob>status%(item_number)=flag

where <F102>item_number<F> is the number of the menu item and <F102>flag<F> is one of the following values:

<$table2>80 Enabled, no tick

<$table2>336 Enabled and ticked

<$table2>0 Light (disabled)

The default status for some items is set just after the initialisation of the menu structure. Of course the contents of the array are not passed to the GFA BASIC menu handler automatically. This job is done by the <F102>menu_status<F> procedure which uses a version of the MENU command to set the menu item status. This procedure must be called whenever the menu is switched on after being off, or whenever an item’s status is altered while the menu is turned on.

<$hb>Menu Handling

The menu bar is set into action near the end of the <F102>initialise<F> procedure. Here the menu is turned on, given the latest status information using a call to <F102>menu_status<F>, and instructed to call the <F102>branch<F> procedure upon a menu item being selected.

After the initialisation procedure is complete an endless DO…​LOOP loop is entered which continually checks for menu activity using the SLEEP command. On selection of an item (i.e. when the user has pulled a menu down and clicked on one of the options) the <F102>branch<F> procedure is automatically called by the GFA BASIC menu handler.

When called the <F102>branch<F> procedure immediately switches off the menu bar to stop confusion occurring due to options being selected while other options are being carried out. The procedure then branches off to one of 11 different procedures depending on the item selected (the item’s number is returned by the GFA BASIC menu handler in element zero of the built-in <F102>menu()<F> array).

On returning from the selected procedure the menu is switched back on and its status updated by calling the <F102>menu_status<F> procedure. The <F102>branch<F> procedure then returns control to the menu testing loop at the head of the program. The various procedures called from <F102>branch<F> perform all the program’s main operations and are discussed below.

<$hc>Desk_About

This very simple procedure is called to display an alert requester proclaiming the name and source of the program whenever the about this program option is selected from the file menu. The procedure first initialises the local integer variable, <F102>button%<F>, before calling <F102>bar_text<F> to display a description of the action selected in the main window’s title bar. After this and a quick piece of house-keeping the procedure’s main function, the creation of the alert requester, is carried out. This is performed using the GFA BASIC ALERT command for which the syntax is:

<$ob>ALERT dummy,message$,default,button$,button%

where:

<F102>dummy<F> is a dummy variable, ignored in Amiga versions of GFA BASIC up to at least 3.5

<F102>message$<F> holds the message to be displayed, in which the vertical bar character (|) is used to mark the beginning of a new line).

<F102>default<F> holds the number of the default button, which will be displayed with a thickened outline and automatically selected if the <Return> key is pressed while the alert requester is on the screen. It is possible to have no default button by placing a zero here.

<F102>button$<F> holds the text for one, two or three buttons, separated by vertical bars (|).

<F102>button%<F> is a variable in which the number of the chosen button is returned after it has been selected. Note that the buttons are numbered consecutively as they appear in <F102>button$<F>, starting from 1.

The ALERT command has been explained in detail because it is widely used in the Julia set program for conveying messages to the user. It is particularly useful in a program of this sort because the screen area obscured by the alert requester is automatically restored when the requester is removed.

The structure of this procedure is similar to all procedures called as a result of a menu item being selected, with the declaration of local variables and the calling of <F102>bar_text<F> prior to performing the selected actions.

<$HC>Dummy

Calls to <F102>dummy<F> are included in the ON GOSUB line of the <F102>branch<F> procedure to fill in the gaps where no procedure needs to be called (e.g. where unselectable dotted lines are included as menu options). As careless typing could cause <F102>dummy<F> to be called instead of the correct procedure, a procedure definition for <F102>dummy<F> has been included which displays an alert requester warning of the error.

Creating, or zooming into, a Julia set takes a relatively long time and it is therefore useful to be able to save the image on the screen to disk.

<$fc>Figure 5.3: Julia set with a=0.32, b=0.043 (24 pin)

<$fc>Figure 5.4: Julia landscape produced using techniques from Chapter 7

<$fc>Figure 5.5: The menu structure of the Julia set exploration program

The actual format used for the Julia files will vary depending on what you intend to do with them, obviously a standard format such as IFF would be ideal for importing into other programs but this would make it hard to incorporate the constants for the set in the file. The reward for including the constants is that it is then possible for the program to tell exactly what part of what Julia set has been loaded.

The <F102>file_load<F> and <F102>file_save<F> procedures provided in Listing 5.1 incorporate only the necessary user interface routines, but they have been written in such a way that it is a simple task to include your own file handling code.

<$fc>Figure 5.6: Julia set with a=-0.75, b=-0.11 produced by Listing 5.2

<$hc>File_load

If the status of menu option 3 is set to 16 (if the Julia set currently in memory has not been saved) confirmation of the menu selection is sought using an alert requester. This step is necessary as loading a new file overwrites the set previously in memory. If the user confirms the intention to load a new file a file selector is displayed using the FILESELECT command, the syntax for which is:

<$ob>FILESELECT title$,buttontext$,searchpath$,selected$

where:

<F102>title$<F> holds a message to be displayed at the head of the file selector window.

<F102>buttontext$<F> provides the text which is to be placed on the confirmatory button.

<F102>searchpath$<F> contains the path to the directory (drawer) in which the file is to be found and also provides a suggested file to load. A typical searchpath string might be <F102>"DF0:/CHAOS/Untitled"<F> which would cause the file selector to display all the files in the ram disk’s CHAOS directory and would provided the name Untitled as a file suggestion.

<F102>selected$<F> is a variable in which the full name (including the path) of the selected file is returned. An empty string is returned if the cancel button is hit.

The relevant picture loading routine should be included at the point indicated in the listing so that once a file has been successfully selected the procedure goes on to open it for input and load the picture. After successfully loading the file the zoom in and view parameter menu options are enabled, and a tick is placed next to the save option (obviously if the file has been loaded from disk it must already have been saved). If the file does not exist an alert requester is generated to inform the user of the problem.

<$hc>File_save

This procedure is very similar to <F102>file_load<F> but many of the checks are not performed as we know that the file will exist. Again, the actual file handling code is missing but the basic structure is in place. After the file has been successfully saved a tick is placed next to the save menu item (item 3) by setting the 3rd element of the <F102>status<F> array to 1. Note that there is no disk full or write protection check, and any file of the same name as the one being saved could be overwritten without warning.

<$HC>File_delete

It is sometimes necessary when saving Julia plots to delete old files to make room for the new one. This can leave the user in a bit of a predicament if a delete menu option is not included. The operation of this procedure is very simple, relying on the FILESELECT command discussed above for file selection and using the KILL command to delete the selected file.

<$HC>File_Quit

This procedure is called when the user indicates the desire to leave the program, by selecting the quit option from the file menu. Because of the severity of this action a confirmatory alert requester is displayed before returning to the editing screen (returning to the Workbench screen if the program has been compiled).

<$HC>Picture_julia

Apart from loading a file from disk the only way to get a Julia set on the screen is by selecting the plot Julia set option from the picture menu. <F102>Picture_julia<F> is the procedure called when this option is selected. If there is an unsaved set on the screen when the option is chosen the program produces a confirmatory alert requester before going on to set the <F102>xmin, xmax, ymin, ymax<F> and <F102>max_iteration%<F> variables to their default values for a full set plot. A window is then displayed in the bottom left of the screen in which the user must enter the two parts of the constant required to draw the set. The window is opened with the <F102>open_window<F> procedure and closed after use by a call to <F102>close_window<F>. The save, zoom and view parameters menu items are then enabled, as they now represent viable options, and the <F102>plot_set<F> routine is called to draw the set. <F102>Plot_set, open_window<F> and <F102>close_window<F> are described later.

<$HC>Picture_zoom

In many respects this procedure is similar to <F102>picture_julia<F> because it initiates the drawing of a Julia set using the <F102>plot_set<F> routine. The differences are that the constant need not be entered because it is inherited from the set already on the screen, but the dimensions of the set and the iteration ceiling are selected to determine the section of the set instead. The user selects the area to enlarge simply by moving to the relevant area, holding the left mouse button down and dragging an 'elastic' rectangle out from the point until the desired area is enclosed (pressing the right hand button will cancel the process at this stage).

This action is simple from the user’s point of view but, behind the scenes, there is a lot of activity. As well as animating the rectangle in such a way that it does not distort the set already on display the program also keeps the aspect ratio of the rectangle the same as that of the screen. Therefore the magnified section of the set does not have to be artificially elongated when plotted. Once the rectangular area has been selected a series of calculations is performed to determine the values of the <F102>xmin, xmax, ymin<F> and <F102>ymax<F> variables for the new plot and a value for <F102>max_iteration%<F> (the iteration ceiling) is determined. The value of <F102>max_iteration%<F> is increased proportionally to the level of magnification because the more detailed the plot the more calculations are required to distinguish between different types of points.

The rule used to calculate the iteration ceiling was arrived at empirically because the complex nature of Julia sets prevents us from ever knowing accurately the amount of detail likely to be visible in the enlarged section. Also the result of <F102>(max_iteration% MOD 16)<F> must always be zero so that the set is black in the centre, in line with the accepted conventions.

<$HC>Picture_parameter

As well as displaying the constant for the set currently on the screen (and its position on the Julia plane) this procedure also displays the iteration ceiling, in an editable text field. This latter option is very useful as it allows the user to alter the level of detail resolved, either to speed up plotting or to by-pass the somewhat inaccurate method of calculation used when zooming into a set.

The procedure uses <F102>open_window<F> and <F102>close_window<F> (both discussed shortly) to manipulate the window in which the information is displayed. Two notable GFA BASIC functions are used in <F102>picture_parameter<F>: PRINT USING which is employed to format the floating point numbers, and FORM INPUT which places a string on the screen, allows the user to edit it and then returns the result. Note that some conversion between strings and numeric variables (using STR$ and VAL) must be performed here because the variable being edited, <F102>max_iteration%<F>, is numeric and FORM INPUT will only accept strings.

<$hc>Picture_print

This procedure is called when print is selected from the picture menu and, after seeking confirmation from the user, it dumps the current screen image to a printer using the HARDCOPY command. HARDCOPY is a built-in GFA BASIC command which prints in whatever graphics format is selected in your Workbench preferences file.

<$hc>Colour

The <F102>colour<F> procedure deals with all three options of the colours menu, and is used to select the way in which the set is displayed. The structure of the procedure differs slightly from that of others called from the menu handler, in that no message is placed in the menu bar because the speed of the procedure is such that the user would not have time to read it. After initialising the local variables a FOR…​NEXT loop is entered in which the selected option has a tick placed next to it by amending the relevant <F102>status%<F> entry. The other two options have their status set to zero (unticked). This loop ensures that only one option can be ticked at a time. Note that this procedure in no way alters the way in which the set is drawn, it merely changes the status array to allow the plotting procedure to know which option should be used the next time it is called.

Because there are so many similarities between the Julia and Mandelbrot sets, many of the ideas discussed at the end of Chapter 4 are also relevant here (3D landscape plotting and interior structure, for example). However, menu options for drawing Julia sets in these different ways would obviously be very useful. Alternatively, separate programs could be written to perform these tasks using information from files created using the original Julia program.

Although every plant species, and every individual within that species, is different it is easy to distinguish between plants and other objects just by looking at them. The way humans do this is to recognise a particular set of characteristics peculiar to plants. If the object we are trying to identify exhibits most of the characteristics from this set we can be fairly sure that it is a plant, even if we have never seen a plant of the same species before. To draw plants which are recognisable as such we need to know what these characteristics are, and how they can be re-created. This is not something specific to computer generated plants, artists also work in this way.

By briefly observing a variety of common plants a short list of features can be constructed which describes the silhouette of a typical plant. The list reads as follows:

<$bullet>A single stem protrudes from the ground with many branches

<$bullet>Most branches split into several smaller sub-branches until the smallest branches (e.g. twigs in trees) are reached

<$bullet>Each plant has a large number of branch ends

<$bullet>The nature of the branching is consistent throughout the plant.

Any biologist could easily discredit this definition, by quoting numerous examples which contradict it, but it serves as a good visual guide for the majority of plants. Note that flowers, fruit and leaves are not mentioned so as to keep the list valid for any time of the year and for as many plant types as possible.

Some of the characteristics typifying plants have been mentioned elsewhere in this book when describing fractals, the most obvious example being the branching of the Feigenbaum diagram. Because the branching is consistent throughout the length of the fractal the Feigenbaum diagram is said to be self-similar. Plants can also be shown to be self-similar using the same argument. A fern, for example, is composed of many miniature fern shapes, each closely resembling the plant of which it is part. Similarly the tiny veins on the underside of a leaf give a good approximation of the structure of the parent tree because, as stated above, the nature of the branching is the same throughout the tree.

Also like our computer generated fractals, the complex structure of a tree is created from a very simple process. Plants must have a large leaf-to-size ratio in order to trap as much light as possible for energy-gathering during photosynthesis. The best way for a plant to achieve this is to make every branch split into many sub-branches to create as many branch ends, hence as many leaves, as possible. This simple process is actually very successful in creating a very large surface area on which light can be trapped. To demonstrate the difference in surface area between a tree and a similar geometrical shape imagine painting a Christmas tree. You would need much more paint to cover its intricate structure of branches and needles than you would to cover a smooth faced cone of the same size.

In having such a large surface area trees are like the Mandelbrot and Julia sets, whose boundaries use up more space than expected for the number of dimensions in which they exist. By continuing this train of thought it is possible to give real plants, which exist in three dimensions, a fractal dimension of just over three. Because of this, and their self-similarity, plants can be classed as fractals, and by thinking of them in this context they can easily be drawn using similar methods to those employed in the fractal generators of earlier chapters. The exact set of rules, or algorithm, for drawing trees on a computer can be determined simply by observing the branching structure of plants in detail. Fractal plants, unlike previous fractals in this book, are created using a rule-based iterative process, rather than a mathematical one. This means that the process is easy to understand, but incorporating it into a program can be a challenge due to the reluctance of computers to deal in anything other than numbers.

The basic branching algorithm is relatively simple, but before considering this in depth we must devise a method of describing the structure of a plant which the Amiga can deal with. Not surprisingly GFA BASIC doesn’t have built-in data structures for storing descriptions of trees! For demonstration purposes we can try to build up a description of the grass shown in Figure 6.1. This plant is referred to as a grass because it is simple in structure and only branches in one direction, making the principles easier to understand.

<$fc>Figure 6.1: Example of a simple grass

The first thing that can be done to make the grass easier for the computer to handle is to split it up into straight segments of uniform length (see Figure 6.2). By doing this the branch lengths are said to be quantised, with the smallest possible branch being one segment long, and the length of every branch being a multiple of one segment length. Angles are also quantised for convenience, in steps of 45 degrees. Curved branches can be built up by putting several angled segments together. For more realistic, more detailed, plants shorter segments and smaller angles should be used, but because longer descriptions are needed to store such plants the values given above will be used in this initial discussion.

<$fc>Figure 6.2: Segmented version of Figure 6.1 which the computer can deal with

Simple notation can now be used to describe such plants using just three characters. The string shown below for the grass in Figure 6.2 will be used as the basis for the following discussion.

"1[1]1[11]"

This is a normal ASCII text string, not the most efficient method of storage as there are only three possible characters, but it is easy to deal with in GFA BASIC and makes future expansion simpler.

Each branch segment is represented in the string by the one character (1). The square brackets are collectively used to describe the tree’s branches, where an open bracket ([) represents a 45 degree clockwise split from the current position (this usually represents the start of a branch) and a closed bracket (]) represents the end of a branch. Whole branches can easily be identified in such strings, as they are like miniature trees, with an equal number of open and closed brackets surrounding them. For example the [1] in the above description represents the first 45 degree branch.

Branches can also be given sub-branches. For example the longer branch ([11]) could be changed to [1[1]1], meaning that it had a single segment branching off at 45 degrees halfway along its length. The grass with this altered branch is shown in Figure 6.3.

<$fc>Figure 6.3: The grass with description "1[1]1[1[1]]"

Curved branches may also be described using this notation. The 180 degree curve in Figure 6.4 is described using the string:

"1[1[1[1[1]]]]"

<$fc>Figure 6.4: 180 degree curve in steps of 45 degrees

This is a particularly good example of how an open bracket does not necessarily represent the beginning of a new branch. The versatility of the notation means that it is possible to describe any plant which only branches in one direction, no matter how complex it is.

In order to write a BASIC program to turn such strings into pictures on the Amiga’s screen we must define a method of interpreting each character into an action that the program can perform. To do this it is necessary to formulate a precise course of action for each of the three characters mentioned above. These actions are as follows:

<$hang1>1 Segment: Draw a uniform length line from the current position, at an angle equal to that held in the current angle count. The end of the new branch becomes the new graphics drawing position.

<$hang1>[ 45 degree clockwise split: Add 45 to current angle count.

<$hang1>] End of branch: Return to the beginning of the current branch (i.e. where the matching open bracket occurred) and decrease the angle count by 45 degrees.

The terms angle count and drawing position are best described using the turtle analogy on which the Logo programming language is based. Instead of the conventional approach of plotting points and lines at the graphics cursor, we imagine that a graphics turtle is being used. In this context a turtle is similar to a cursor in that it can be placed at any pixel position on the screen, but in addition to a position the turtle also has an angular direction associated with it (the angle count). The direction is usually specified in degrees with zero being vertical and positive angles representing clockwise rotation from the vertical. Negative values are used to indicate anti-clockwise angles. Note that a line drawn from the current turtle position does not need to have its destination specified, as this is automatically calculated from the length of the line and the angle count. Figure 6.5 shows the path that a logo-type turtle would take when plotting the plant described by the example string introduced above.

Experienced GFA BASIC users will know that the language has a suite of built-in commands to facilitate Logo-style drawing. I have, however, refrained from using such features here in order to make conversion to other languages easier.

<$fc>Figure 6.5: The path followed by a Logo turtle plotting the grass in Figure 6.3

The three actions have been incorporated into the <F102>draw_plant<F> procedure in Listing 6.1, which is used to draw the grass from Figure 6.3. Note that GFA BASIC does not support turtle graphics so the program uses simple trigonometry to convert between the actions and the DRAW TO command. Note that <F102>draw_plant<F> merely turns the string supplied in <F102>plant$<F> into a drawing, it doesn’t actually generate plants.

<$ob>COLOR 1<$ob>plant$="1[1]1[1[1]1]" !Put sample string into plant$<$ob>unit_length=10 !Set up constants for unit length…​<$ob>unit_angle=PI/4 !…​and unit angle<$ob>'<$ob>GOSUB draw_plant !Call procedure to draw the plant <$ob>'<$ob>PROCEDURE draw_plant<$ob> angle_count=0 !Initialise angle count<$ob> pointer=0 !Set up initial string pointer position<$ob> GOSUB draw_branch(320,180)<$ob>RETURN<$ob>'<$ob>PROCEDURE draw_branch(x,y)<$ob> INC pointer !Increment pointer position and…​<$ob> character$=MID$(plant$,pointer,1) !…​note character in that position<$ob> '<$ob> REPEAT<$ob> SELECT character$<$ob> CASE "1" !If the character is a 1, draw a segment<$ob> PLOT x,y<$ob> x=x+SIN(angle_count)*unit_length*2<$ob> y=y-COS(angle_count)*unit_length<$ob> DRAW TO x,y<$ob> '<$ob> CASE "[" !If it’s a [ then branch off<$ob> ADD angle_count,unit_angle<$ob> GOSUB draw_branch(x,y)<$ob> ENDSELECT<$ob> INC pointer !Note next character<$ob> character$=MID$(plant$,pointer,1)<$ob> UNTIL character$="]" OR character$=""<$ob> '<$ob> SUB angle_count,unit_angle !If it’s a ] (end of branch) then<$ob>RETURN !decrease angle count and return <$fc>Listing 6.1: The <F102>draw_plant<F> procedure and sample calling code

The first section of the program initialises all global variables before calling the procedure to plot the plant. The variables are defined as follows:

<$hang1><F102>plant$<F> Holds the string describing the grass, in plant generation programs later in this chapter the string will be created by the program.

<$hang1><F102>unit_length<F> Is the uniform segment length in low resolution pixels. This and <F102>unit_angle<F> are variable so as to enable easy experimentation.

<$hang1><F102>unit_angle<F> Determines the angle at which branches split off. In this example it is 45 degrees, but as GFA BASIC only accepts radians it must be set to the equivalent radian value of PI/4 (see Appendix B for details of conversions).

<$hang1><F102>angle_count<F> Is used by the <F102>draw_branch<F> procedure to store the current angle count, described above.

<$hang1><F102>pointer<F> Is used to store the current position in the string, i.e where to look for the next character to interpret. It is initially set to 0 because the first thing that the <F102>draw_branch<F> procedure does is increment it (see below).

After initialisation the <F102>draw_branch<F> procedure is called with the arguments 160 and 180. These are the x and y co-ordinates of the current drawing position that initially define the position of the bottom of the plant’s stem.

The second section of the program is the actual definition of the <F102>draw_branch<F> procedure. It is not immediately obvious how this operates, but all the techniques used are perfectly legal and can easily be understood if analysed logically. The first task of draw_branch is to increment the string pointer and copy the character at that new position in <F102>plant$<F> into the <F102>character$<F> variable. A REPEAT…​UNTIL loop is then entered which checks for the open square bracket ([) and one (1) characters.

If the loop detects that the character is a 1 a segment of unit length is drawn at the current angle. This results in the end of the new line becoming the current drawing position. The next character is then extracted from the string, and if it is not a closed square bracket the loop then repeats.

If the character is not a 1, but an open square bracket, the <F102>unit_angle<F> value is added to the current angle count and the <F102>draw_branch<F> procedure is then called with the latest x and y arguments. If this happens the REPEAT…​UNTIL loop does not continue until the <F102>draw_branch<F> call returns.

If a closed bracket is taken from the string, or the end of the string is reached (<F102>character$=""<F>), the REPEAT…​UNTIL loop is terminated, <F102>unit_angle<F> is subtracted from the angle count and the procedure returns to where it was called. In GFA BASIC the only time a procedure can return cleanly is at its end. This is obviously true for <F102>draw_branch<F>. Usually the procedure will return to the open bracket clause of the IF…​ENDIF construct. However, in the case where the end of the string has been reached the procedure will automatically return to where it was first called, at the head of the program, resulting in the termination of the procedure and a return to the editing screen.

The method used here of calling a procedure from inside itself is known as recursion and, although a very powerful tool, it is sometimes hard to follow. Its use not only means that the same procedure can be used to draw all manner of branches, from twig to whole plant, but also means that we do not have to waste time and memory keeping track of where branching points occurred on the screen. Each time the <F102>draw_branch<F> procedure invokes itself the previous group of arguments are stored by BASIC on a kind of internal stack. This means that as the procedure returns to where it was called the old values of <F102>x<F> and <F102>y<F> are taken off the stack and automatically become the current drawing position co-ordinates.

It is easy to experiment with different grasses by just altering the description string at the start of the program. Note that any valid string may be used but plants represented by particularly long strings may not fit on the screen. In this case you should reduce the <F102>unit_length<F> and <F102>unit_angle<F> constants as necessary. Some of the examples given later suggest suitable values for these constants which vary from the customary 10 pixel and 45 degree assignments. The most important thing to ensure, when trying to create a natural looking plant, is that each open bracket has a matching closed bracket.

Interesting though the plant drawing program is, it will not actually generate plant descriptions. If you want a detailed piece of grass you have to type in a long string, which does not necessarily look very realistic. It is a fairly trivial matter to write a procedure to generate a plant’s string description now that the necessary notational conventions have been established. Like other fractals, plants are generated using a simple, structure enriching, iterative process. The process used here is initially quite simple, but can be enhanced fairly easily. Basically every iteration sees each segment being replaced by a larger, more complex branch, thus making the plant larger while keeping the same level of relative complexity. This is achieved in the program by searching through the whole plant description (<F102>plant$<F>), replacing all the 1 characters with a more complex user-defined string, set to determine the type of plant.

Listing 6.2 contains the <F102>replace_chars<F> procedure to accomplish this task, along with the old plant drawing routine. In this example all 1s are replaced by the contents of <F102>one$<F>, initially set to "11[1[1[1]]]", although any valid plant-type structure may be used. The plant description with which the program starts is the simplest possible structure, "1". It is important to note that there is no easy way to insert characters into a string, so what the program actually does is copy the contents of <F102>plant$<F> into the variable <F102>newplant$<F>, character by character. However, if a one is found then the replacement string is copied across instead. Once the replacements are complete the contents of <F102>newplant$<F> are copied back to <F102>plant$<F> and <F102>newplant$<F> is cleared ready for the next iteration.

<$ob>COLOR 1<$ob>plant$="1"<$ob>one$="11[1[1[1]]]"<$ob>unit_length=2 !Set up unit length…​<$ob>unit_angle=PI/16 !…​and unit angle<$ob>'<$ob>REPEAT<$ob> CLS<$ob> GOSUB draw_plant !Draw plant so far <$ob> GOSUB replace_chars !Make plant grow<$ob>UNTIL MOUSEK=2<$ob>'<$ob>PROCEDURE draw_plant<$ob> angle_count=0 !Initialise angle count<$ob> pointer=0 !Set up initial string pointer position<$ob> GOSUB draw_branch(320,180)<$ob>RETURN<$ob>'<$ob>PROCEDURE draw_branch(x,y)<$ob> INC pointer !Increment pointer position and…​<$ob> character$=MID$(plant$,pointer,1) !…​note character in that position<$ob> '<$ob> REPEAT<$ob> SELECT character$<$ob> CASE "1" !If the character is a 1, draw a segment<$ob> PLOT x,y<$ob> x=x+SIN(angle_count)*unit_length*2<$ob> y=y-COS(angle_count)*unit_length<$ob> DRAW TO x,y<$ob> '<$ob> CASE "[" !If it’s a [ then branch off<$ob> ADD angle_count,unit_angle<$ob> GOSUB draw_branch(x,y)<$ob> ENDSELECT<$ob> INC pointer !Note next character<$ob> character$=MID$(plant$,pointer,1)<$ob> UNTIL character$="]" OR character$=""<$ob> '<$ob> SUB angle_count,unit_angle !If it’s a ] (end of branch) then<$ob>RETURN !decrease angle count and return<$ob>'<$ob>PROCEDURE replace_chars<$ob> pointer=0 !Set initial pointer position<$ob> REPEAT<$ob> INC pointer !Increment pointer position<$ob> character$=MID$(plant$,pointer,1) !Extract character<$ob> SELECT character$<$ob> CASE "1" !If it’s a 1 then replace it with one$<$ob> newplant$=newplant$+one$<$ob> DEFAULT<$ob> newplant$=newplant$+character$ !Otherwise leave it unchanged<$ob> ENDSELECT<$ob> UNTIL pointer=LEN(plant$)<$ob> plant$=newplant$ !Replace old plant$ with new one<$ob> newplant$="" !Clear newplant$ just in case<$ob>RETURN <$fc>Listing 6.2: The <F102>draw_plant<F> and <F102>replace_chars<F> procedures being used together to generate and plot a grass

If you type in and run the program a tiny vertical sprig of grass will appear at the bottom of the screen, which will then begin to grow. Figure 6.6 shows the appearance of the grass on successive iterations. Note that as the plant, and hence its string description, gets more complex the iterations take considerably longer to perform. If you have a compiler you may wish to use it here, although the calculations are still quicker than those required to plot the Mandelbrot set.

<$fc>Figure 6.6: The appearance of the grass with replacement string "11[1[1[1]]]" during the first six iterations

There are no limits imposed by the plant algorithms regarding the number of iterations performed but complexity is limited because GFA BASIC can only cope with strings of less than 32,768 characters. If the plant’s description goes beyond this limit an error message will be displayed and the program will terminate. This is not as great a limitation as it seems because such complex plants could only be accommodated by the screen with a major loss of detail.

The program produces some quite interesting, sometimes unexpected, results making experimentation very worthwhile. Table 6.1 shows some notable values for <F102>unit_angle, unit_length, plant$<F> and <F102>one$<F>. When using your own values be sure to have matching brackets, and also try to plan ahead so that the tree gets larger as well as getting more complex. For example a replacement for one of "11[1]" will cause the replaced branch to get longer whereas "1[1]" will just change it into a two branches, each similar in length to the original.

<$tc>Table 6.1: Variable assignments for a variety of grasses

<$table4> <F102>plant$ one$ unit_length unit_angle<F>

1 1 1[11[[1]]] 3 PI/12

1 1 [1]1[[1[[1]]1[[1]]]] 4 PI/16

1 1 1[1[[1[1[[1]]]]]] 4 PI/16

<$ha>Trees

Only grasses have been drawn thus far because their branches split off in a single direction. Now that the basic algorithm has been established it is fairly easy to alter it for the bi-directional type of branching found in trees and shrubs. All that needs to be done is to add two new characters, the curly brackets ({ and }), to the set recognised by the <F102>draw_branch<F> plant visualisation procedure. The curly brackets are used to enclose descriptions of branches which split off anti-clockwise. The relevant actions for each curly bracket, shown below, are very similar to those associated with the equivalent square brackets.

<$hang1>{ Anti-clockwise split: Subtract <F102>unit_angle<F> from current angle count.

<$hang1>} End of branch: Return the graphics cursor to the beginning of the current branch (i.e. where the matching open bracket occurred) and increase the angle count by <F102>unit_angle<F>.

Listing 6.3 shows the adapted definition of the <F102>draw_branch<F> procedure required for bi-directional branching. The program code used to check for and act on curly brackets is very similar to that for square brackets. There is no need to edit the definition of <F102>replace_chars<F> because brackets are not replaced under any circumstances.

<$ob>PROCEDURE draw_branch(x,y)<$ob> INC pointer !Increment pointer position and…​<$ob> character$=MID$(plant$,pointer,1) !…​note character in that position<$ob> '<$ob> REPEAT<$ob> SELECT character$<$ob> CASE "1" !If the character is a 1, draw a segment<$ob> PLOT x,y<$ob> x=x+SIN(angle_count)*unit_length*2<$ob> y=y-COS(angle_count)*unit_length<$ob> DRAW TO x,y<$ob> '<$ob> CASE "[" !If it’s a [ then branch off clockwise<$ob> ADD angle_count,unit_angle<$ob> GOSUB draw_branch(x,y)<$ob> CASE "{" !If it’s a { then branch off anti-clockwise<$ob> SUB angle_count,unit_angle<$ob> GOSUB draw_branch(x,y)<$ob> ENDSELECT<$ob> INC pointer !Note next character<$ob> character$=MID$(plant$,pointer,1)<$ob> UNTIL character$="]" OR character$="}" OR character$=""<$ob> '<$ob> SELECT character$<$ob> CASE "]" !If it’s a ] (end of branch) then<$ob> SUB angle_count,unit_angle !decrease the angle count..<$ob> CASE "}" !If it’s a } then increase angle…​<$ob> ADD angle_count,unit_angle<$ob> ENDSELECT<$ob>RETURN !…​and return from the procedure <$fc>Listing 6.3: Adapted definition of draw_branch for bi-directional branching

If you haven’t altered the definition of <F102>plant$<F> and <F102>one$<F> at the start of the program you will see exactly the same output as before. However, the whole program can now cope with curly brackets and if the variables are set to some of the values from Table 6.2 trees with bi-directional branching will be generated. Note that it is perfectly natural for anti-clockwise branches to have clockwise sub-branches and vice-versa. Some example trees are shown in Figures 6.7 and 6.8.

<$fc>Figure 6.7: Tree produced using the fourth set of values from Table 6.2

<$fc>Figure 6.8: Tree produced using the third set of values from Table 6.2

<$tc>Table 6.2: Variable assignments for a variety of trees

<$table4><F102>plant$ one$ unit_length unit_angle <F> <$table4>1 11{1{1}[1]}[1[1{1}]] 3 PI/8 <$table4>1 11[1[[1[1[[1]]]]]]{1{{1{1{{1}}}}}} 4 PI/16 <$table4>1 11[1{1}1]{11[1]1} 3 PI/8 <$table4>1 1{{11}}[[11]]1[{{11}}[[11]]1[{{1}}[[1]]1]] 8 PI/10

The plant generation program developed in this chapter can also be used to create a wide variety of non-biological structures. For example, by replacing the variable assignment lines with those shown below it is possible to produce a very complex snowflake structure (see Figure 6.9).

<$fc>Figure 6.9: Snowflake generated using the plant program

Naturally the character replacement technique is exactly the same as that used for the plants above, and even the replacement string looks familiar, but in this case the plant initially has six branches, each one at 60 degrees to its neighbour. In this example <F102>one$<F> specifies that each segment should be replaced by a slightly longer segment with a bifurcation at the end. Note that because the strings include curly brackets they can only be implemented in the bi-directional plant drawing program.

<$ob>plant$="{{{11}}}{{11}}{11}[11][[11]]11" <$ob>one$="11[1]{1}" <$ob>unit_length=1 <$ob>unit_angle=PI/3

In addition the origin of the plant must be moved from the bottom of the screen to the middle, because the flake grows in all directions. The plant’s origin is changed by altering the line which calls the <F102>draw_branch<F> procedure so that it reads:

<$ob> GOSUB draw_branch(320,100)

which causes a different initial drawing position to be sent to the procedure.

It is accepted that every snowflake should be unique in structure. This is hard to achieve on a computer but the structure of the one in the plant program can be drastically altered by simply changing the contents of <F102>one$<F>. As an example, "11[1]{1}1" would give trifurcations at the end of each branch.

Growing artificial plants is a very interesting pastime, so I have attempted to write the accompanying program in such a way as to make experimentation in this area as easy as possible. The way the fractal grows can be altered simply by changing the few variables initialised at the start of the program. Many other natural fractal patterns such as lightning and frost on a window can be created using the methods and programs discussed in this chapter. A variety of more specific enhancements are outlined below.

On a two dimensional plane, such as that used to display most graphs, there are two directions of movement, represented by two axes at right angles to one another, as shown in Figure 7.1.

<$fc>Figure 7.1: Typical two dimensional plane

The two directions of movement are vertical (represented by the y axis) and horizontal (represented by the x axis). In three dimensional space, however, there is an additional direction of movement, and hence three axes (x, y and z). As the screen of the Amiga is only two dimensional it is of course impossible to display three dimensional objects, but take a look at Figure 7.2.

<$fc>Figure 7.2: Isometrically drawn three dimensional space and cube

This shows the three axes used to represent three dimensional space, with a cube placed where they meet. Obviously this diagram is not really three dimensional, but the illusion of three dimensions is produced sufficiently to convey the fact that the object shown is a 3D cube. This effect is achieved by plotting the x and z axis as normal but drawing the y axis at 30 degrees to the x axis, and treating all corresponding movements in the y direction in the same way. The technique is called isometric drawing and is frequently used by draughtsmen when producing illustrations of their designs, and can also be found in some computer games and demos. Drawing objects such as spheres and cubes isometrically can be a fairly complicated process as a method must be devised for storing the structure of objects, but plotting landscapes is somewhat easier due to landscapes simply being uneven planes.

<$fc>Figure 7.3: Mathematical splitting of y into horizontal and vertical components

To perform isometric drawing in GFA BASIC an algorithm is required to convert a three dimensional (x,y,z) co-ordinate to the two dimensional form accepted by the BASIC PLOT and DRAW functions. This algorithm involves splitting the isometrically drawn y position into its constituent horizontal and vertical components, as shown in Figure 7.3, and adding these components to the x and z positions for the point. By merging y with x and z in this way we have effectively eliminated y and are now left with a two dimensional co-ordinate of the form (x,z) which can be used directly with PLOT, POLYLINE or any other graphics function available from BASIC.

If the components of y are to be added to x and z to produce a composite co-ordinate it is necessary to determine the size of the components. This is done by calculating the ratio between them using elementary trigonometry, and since it is a ratio, rather than an absolute value, it is the same for any value of y. The mathematical tangent function can be used to find this universal ratio because the tangent of an angle is defined as the ratio of the length of the angle’s opposite and adjacent sides in a right angled triangle. From Figure 7.3 it is clear that the ratio of the z component to the x component is the tangent of 30 degrees. The value of this tangent can be found using the tan button of a pocket calculator, which should return a result of approximately 0.6. The mathematical interpretation of this process is shown below (angles, right angled triangles and the tangent function are discussed in detail in Appendix B).

<$table5>tan 30 = z component = 6 (or 0.6 or 6:10) <$table5> x component 10

Now that the ratio of the z component to the x component is known it is possible to plot points on the screen isometrically. The method for doing this is best conveyed by the example plane drawing program in Listing 7.1. Here a pair of FOR…​NEXT loops are used to completely traverse a 48x48 point plane, on which each point is plotted isometricaly. The (x,y) position of the point passed to the PLOT command is calculated as follows:

<$table4>Position passed Offset x and z parts y components <$table4>to PLOT <$table4>horizontal = x*5 + 1.7*y <$table4>vertical = 148 - y

There are several important points to note in these equations. Firstly the z position of every point is zero, so this is not included in the calculation of the y position. Secondly the horizontal component of y is equal to 1.7*y and the vertical component is equal to y (or 1*y), so the ratio is correct for 30 degrees (1/1.7 = 0.6). Also note that the vertical position passed to PLOT is inverted by subtracting it from 148 - necessary because of the Amiga’s upside-down vertical axis. The x position is multiplied by 5 to ensure that the maximum screen area is utilised, although in this example the fact that z is equal to zero means that there are large spaces at the top and bottom of the screen.

<$ob>FOR y=47 TO 0 STEP -1<$ob> FOR x=0 TO 47<$ob> PLOT x*10+y*3.4,148-y<$ob> NEXT x<$ob>NEXT y <$fc>Listing 7.1: The plane drawing program

<$fc>Figure 7.4a: Isometric 3D plane produced by Listing 7.1

The plane produced by Listing 7.1 (in high resolution mode) is shown in Figure 7.4a. A landscape could easily be represented here by giving each point a height determined by some particular method, but since each point is plotted as a single pixel, with no connections to adjacent pixels the points would quickly become confused making the image meaningless.

<$fc>Figure 7.4b: Testcard landscape drawn using single pixels

Figure 7.4b shows the single pixel plotting method being used to draw a landscape 'testcard'. A more suitable plotting method involves joining together all points that have the same y position in order to create a series of 48 lines depicting the plane.

<$fc>Figure 7.4c: Testcard consisting of lines

As Figure 7.4c shows this is a great improvement, but the plane appears transparent in places because lines which are meant to be behind or below other parts of the plane can still be seen. The process of removing unwanted lines to make an object appear solid is called 'hidden line removal', the result of which is shown in Figure 7.4d.

<$fc>Figure 7.4d: Testcard drawn using lines and hidden line removal

The best way to remove hidden lines in our case is by using the GFA BASIC POLYFILL command to draw each line and fill the gap between it and the last line drawn, in the background colour. Figure 7.5 shows the way in which a polygon is constructed from the two most recent lines so that the gap between them is totally enclosed and can be automatically filled in.

<$fc>Figure 7.5 Application of filled polygons to remove hidden lines

The programming needed to implement this hidden line removal system is beyond the scope of this book, and unrelated to chaos theory, so an 'off-the-shelf' procedure has been included in Listing 7.2 which draws a plane with hidden lines removed, from the data describing the height of each point stored in the 48x48 element <F102>z%<F> array. The size and position of this plane, and the relationship between <F102>z%<F> co-ordinates and their screen positions are shown in Figures 7.6 and 7.7. This procedure definition will need to be included in all programs given later in this chapter which contain calls to landscape.

<$fc>Figure 7.6: Size of the plane produced by the landscape procedure (in low-resolution pixel units)

<$fc>Figure 7.7: Relationship between elements of the <F102>z%<F> array and the plane drawn by landscape

<$ob>PROCEDURE landscape<$ob> CLS<$ob> DEFFILL 1,0<$ob> BOUNDARY 1<$ob> COLOR 1<$ob> '<$ob> FOR y=47 TO 0 STEP -1 <$ob> FOR x=0 TO 47<$ob> poly_x%(x)=x*10<$ob> poly_y%(x)=-z%(x,y)<$ob> NEXT x<$ob> IF y<47<$ob> FOR x=0 TO 47<$ob> poly_x%(95-x)=x*10+3.4<$ob> poly_y%(95-x)=-z%(x,y+1)-1<$ob> NEXT x<$ob> POLYFILL 96,poly_x%(),poly_y%() OFFSET y*3.4,(148-y)<$ob> REM Enhancements may be added here (see text)<$ob> ELSE<$ob> POLYLINE 48,poly_x%(),poly_y%() OFFSET y*3.4,(148-y)<$ob> ENDIF<$ob> NEXT y<$ob>RETURN <$fc>Listing 7.2: The <F102>landscape<F> procedure, which uses hidden line removal to render a landscape from the contents of the <F102>z%<F> array

Now that we have a method of plotting a landscape we can begin to use chaos techniques to determine the height of each point on the plane, in order to give the landscape a more natural appearance.

There are numerous methods available for producing landscapes with features similar to those found in the real world, and more realistic ones are being produced all the time. Upon looking at a natural landscape it is evident that the process used to set the height of each point on the plane would have to be random, and a first attempt at a landscape program may look like Listing 7.5.

<$ob>DIM z%(47,47)<$ob>DIM poly_x%(95)<$ob>DIM poly_y%(95)<$ob>'<$ob>PRINT "Calculating…​"<$ob>'<$ob>FOR x=0 TO 47<$ob> FOR y=0 TO 47<$ob> z%(x,y)=RANDOM(21)-10 !Set height of point<$ob> NEXT y<$ob>NEXT x<$ob>'<$ob>GOSUB landscape

<$fc>Listing 7.5: A totally random landscape program

This sets the height of each point randomly within the range of -10 to 10, and certainly does not produce a natural landscape, as Figure 7.9 demonstrates.

<$fc>Figure 7.9: Totally random landscape

The problem is that the degree of randomness is too great, causing incredibly steep slopes and sudden points of height to be produced. On a real landscape such steep slopes would be made gentler by a gradual process of weathering. It is true that most landscape generators rely on some kind of random process, but to generate a realistic landscape it is necessary to control the randomness in some way so that it does not get too out of hand, as in the Sierpiński triangle. Two generators based on controlled randomness are presented below.

Earlier in the book it was suggested that some fractals, such as the Feigenbaum diagram and Mandelbrot set may benefit from being displayed in three dimensional landscape form. As we now have the <F102>landscape<F> procedure, which will produce a landscape from the contents of the two dimensional <F102>z%<F> array, such images are easy to create. The same processes and calculations as those used in the original fractals must be followed of course, but instead of plotting to the screen values are placed in the <F102>z%<F> array and plotted later by calling <F102>landscape<F>.

As indicated earlier in this chapter there are many techniques available for generating natural looking landscapes, but only a small selection have been discussed here. Details of more complicated, and more realistic, landscape generators can be found in the books listed in Chapter 9. Even if you find the naturalness of the landscapes given here acceptable it is still possible to improve their appearance in a variety of ways, described below.

The techniques used to plot the Mandelbrot set and Feigenbaum diagram may also be enhanced to produce better quality output, and both Martin fractals (discussed in the next chapter) and Julia sets may be drawn in landscape form using the methods described above.

Of course the common factor linking these images is the process used to draw them, developed by Barry Martin of Birmingham’s Aston University. The process is very similar to those covered at the beginning of the book in that a pair of variables are repeatedly transformed by two non-linear equations and the results plotted on a two dimensional plane, as shown in Figure 8.1.

<$fc>Figure 8.1: Relationship between the two equations and a Martin fractal

This process is particularly similar to the one used to draw the Lorenz attractor except that only two variables are used, rather than three, and the points are simply plotted rather than being joined together. Also, the Martin equations (shown below) are considerably simpler, relying only on a few elementary functions.

xnew=y-SGN(x)*SQR(ABS(b*x-c))

ynew=a-x

Here x and y are the two variables and a, b and c are constants similar to those found in the Lorenz equations. The important parts of these equations are the SGN, ABS and SQR functions, whose BASIC interpretations are shown below.

SGN(x) is used to determine the sign of a number (whether it is positive or negative). The function returns 1 if x>0 (positive), -1 if x<0 (negative) and 0 if x=0.

SQR(x) returns the square root of a number (<214>x). So, for example, SQR(9) would return 3, because 3*3 = 9. More information on square roots and indices can be found in Appendix B.

ABS(x) returns the absolute value of x, in other words the distance of x from 0. This is sometimes useful for checking if a variable is within a certain range. For example <F102>IF ABS(x)⇐3<F> could be used to test whether x is between -3 and +3 inclusive.

The combination of these functions and the feedback between x and y (shown in Figure 8.2) on successive applications of the equations makes the Martin process unpredictable and immensely complex. By plotting x against y on the Amiga’s screen, after each iteration, two dimensional Martin fractals can be created. These demonstrate just how chaotic and varied the output from these two simple equations can be.

<$fc>Figure 8.2: Feedback in the Martin equations

An Amiga BASIC program to perform the Martin process and simultaneously plot the resulting fractal is shown in Listing 8.1. A GFA version of this program is provided later in the chapter.

<$ob>DEFDBL a-c,x,y,xnew,ynew <$ob>REM Request constants<$ob>INPUT "a=",a<$ob>INPUT "b=",b<$ob>INPUT "c=",c<$ob>CLS<$ob>'<$ob>REM Set initial values for variables<$ob>x=0<$ob>y=0<$ob>i=0<$ob>'<$ob>REM Main loop draws fractal and checks for mouse button press<$ob> WHILE MOUSE(0)=0 'Perform Martin process until mouse button is <$ob>pressed<$ob> '<$ob> REM Calculate new values of x and y<$ob> xnew=y-SGN(x)SQR(ABS(b*x-c))<$ob> ynew=a-x<$ob> x=xnew<$ob> y=ynew<$ob> '<$ob> PSET(300+x.8,100-y*.4) 'Plot point<$ob> i=i+1 'Increment iteration count<$ob> WEND <$fc>Listing 8.1: An Amiga BASIC program to perform the Martin process and simultaneously plot the result

Upon running the program you will be prompted to enter the three constants, remember that it is necessary to click in the output window before Amiga BASIC will allow you to respond to these prompts. The values entered for these determine which of the many possible fractals will be drawn. To pilot the program and to demonstrate a typical Martin, if there is such a thing, the following constants can be used:

<$ob>a=45 <$ob>b=2 <$ob>c=-300

After entering the above values, in response to the relevant prompts, you will soon (during the first 5,000 iterations) see a small group of near-perfect circles appear, connected together by pairs of lines, as shown in Figure 8.3a.

<$fc>Figure 8.3a: Martin fractal where a=45, b=2, c=-300 after 5,000 iterations

At this stage it looks more like a network of underground passages than a biological construction. After a short wait (22,000 iterations complete) all of the exits from this network are blocked off and a collection of tiny lines appears in the space outside, see Figure 8.3b.

<$fc>Figure 8.3b: Martin fractal where a=45, b=2, c=-300 after 26,000 iterations

A period of inactivity then follows in which the only sign of change is the creation of a circle in the centre of the fractal. This inactivity is suddenly ended by a 'burst' of growth, which occurs after 85,000 iterations have been completed. This growth is much more sustained than before, continuing until around the 100,000th iteration. The scene after this burst is shown in Figure 8.3c and clearly highlights the new, more natural looking, growth dwarfing the original network.

<$fc>Figure 8.3c The Martin fractal after 70,000 iterations

Further bursts which occur later thicken up existing lines and fill in gaps, eventually producing the picture shown in Figure 8.3d. The main features of this fractal, such as the high level of complexity and the bursting phenomenon are typical products of this program.

<$fc>Figure 8.3d: The Martin fractal after 1,000,000 iterations

Like many other fractals it is very interesting to watch this one grow. By slowing the program down it can be seen that the image is built by pixels being dropped, as if from an invisible satellite in irregular orbit around the centre of the screen. Using this analogy the periods of inactivity seen between the bursts in the above example can be said to be caused by the satellite dropping pixels on top of ones already on the screen, thus making no visible change. This infers that the satellite has predictable periodic behaviour, but this can never be the case with a non-linear dynamic system.

In fact, during periods of inactivity, the satellite is following a subtly different path, too similar to be noticed in the crude approximation produced on the screen. However, the same type of positive feedback that causes the butterfly effect amplifies this small deviation and eventually it suddenly becomes very large, causing the satellite to assume a much different path, noticeable on the screen as a sudden burst of new pixels.

The notion of non-periodicy and the butterfly effect in a system such as this will already be well known from Chapter 3, but the bursting phenomenon is far more visual here than in the Lorenz attractor. These kinds of erratic flurries of activity are also familiar to share dealers, stock brokers, weather forecasters and other people whose professions are concerned with the world of non-linear dynamics. In these areas of the real world such bursts manifest themselves as sharp swings in share prices, sudden drops in temperature and rapid increases in oil prices. It is highly probable that such sudden unexpected events are created by previously unnoticed small changes getting larger by ever increasing amounts.

The now legendary stock market crash of 1987 was apparently due to dealers over-reacting to a small devaluing of stocks, sending shares into a downward spiral. The fall was further magnified by the newly installed computer dealing systems which sold shares instantaneously, without the protective natural damping provided by slower human reactions. Nobody could have noticed the start of this spiral in advance because it would have been too small, meaning that such events can only be spotted when their magnitude is such that they are hard to prevent.

A similar manifestation of the butterfly effect could cause a system, apparently continuing normally, to suddenly collapse without warning. This is an interesting suggestion and has precipitated much debate in recent years. The fact that the weather and the Earth’s eco-system are vulnerable to this type of positive feedback makes the possibility of a sudden end to the human race quite feasible.

The number of different images that can be produced with Listing 8.1 is truly daunting, so a selection of some of the most interesting constants are shown in Table 8.1. Note that although most of these examples will fit on the screen using the current scaling, some of them may benefit from being enlarged. This can easily be done by changing the co-ordinate multipliers in the PSET line. For example the following line will produce output of twice the size:

<$ob>PSET(300+x*1.6,100-y*0.8)

<$tc>Table 8.1: Some interesting constants for the Martin program

<$table3>a b c <$table3>68 75 83 <$table3>90 30 10 <$table3>10 -10 100 <$table3>-200 -4 -80 <$table3>-137 17 -4 <$table3>10 100 -10 <$table3>-137 17 4

The position of the image on the screen may also need to be altered. This can be done by editing the two large numbers in this line, as it is these which collectively determine the offset. An example of a Martin enlargement is shown in Figure 8.4.

<$fc>Figure 8.4: Mathematical enlargement of Figure 8.3d

There is very little point in adding an expeditious user interface to the Martin program because very little input is required. However, there are a few simple enhancements that can be included in other areas of the program.

This concludes our experiments with the imitation of nature, but there are obviously many natural objects that we have not attempted to model, including clouds, smoke, sparks and animals. Some of these can be generated using techniques already discussed in this book, but others will require the formulation of some kind of specialised algorithm. Such algorithms can either be constructed by examining real life objects, as in the last two chapters, or they can be gleaned from other chaos books. Either way the artificial creation of natural images is a very interesting application of computer science, and one which is bound to become very popular as advances in graphics facilities and processing power are made in the future.

<$fc>Figure 8.5: Martin fractal with a=-137, b=17, c=-4 after 30,000 iterations <$fc>Figure 8.6: Martin fractal with a=68, b=75, c=83 after 40,000 iterations <$fc>Figure 8.7: Martin fractal with a=12, b=18, c=256 after 10,000 iterations

Algebra encompasses a wide range of fundamental mathematics principles, but probably its most well know aspect is the use of letters to represent numbers. This allows written statements to be expressed in mathematical form. The letters are known as variables, and have similar properties to the variables found in programming languages, except that they may only be one character long. Algebraic variables may be used in all the same ways as normal numbers. For example the algebraic expression shown below involves addition and multiplication.

y + y + y = 3 * y

The 3*y section would normally be written simply as 3y, but the BASIC notation adhered to in this book means that the longer equivalent must be used. The equation states that any number (here represented by y) added to itself three times equals 3 multiplied by the number. To use this equation values must be substituted in place of y, as an example the equation when y is four is shown below. Note that in BASIC a number can be assigned to a variable using a command of the form <F102>y=4<F>.

4 + 4 + 4 = 3 * 4

This equation holds for any number, and since it is an equation both sides always equate to the same value. Although this example is of little practical use there are many useful equations expressed in a similar form, such as Pythagorus' theorem.

Variables whose values are always the same are known as constants. By convention different variables are used for different number types. For example x, y, z and i, j, k are usually used to represent variables whereas a, b, c, k and Greek letters such as <80> are employed to represent constants. When used alone, z is traditionally used to represent complex numbers, whose constituent parts are usually represented by a for the real part and b for the imaginary one. Apart from having different names there is no distinction between constants and variables in most dialects of BASIC but in C it is possible to declare variables as being static, meaning that they are treated as constants, which are processed faster.

z = a + bi

Commonly known as powers, indices are a very useful mathematical tool, used in many applications. An example of index notation is shown below. The number shown in normal sized type is called the base and the smaller superscript number is known as the index.

24

The equivalent BASIC notation (used in this book), where the base and index are separated by a ^ character, is:

2^4

We say that this example shows 2 to the power of 4, or that 2 is raised to the power of 4. In BASIC the ^ character can effectively be pronounced to the power of. Certain indices have particular names associated with them. For example a number raised to the power of 2 is said to be squared and a number raised to the power of 3 is said to be cubed, e.g. 5^3 is pronounced five cubed. It is also common to say the a number is the square of another number. For example 16 is the square of 4, because 4^2 equals 16. Similarly 125 might be called the cube of 5 (details of how to calculate these values are given below).

In its simplest form index notation is basically a quick way of expressing calculations which would otherwise be quite tiresome to write. The index denotes how many times the base is multiplied by itself, so the actual value of 2^4 can be calculated as shown below.

<$table3>2^4 = 2 * 2 * 2 * 2 = 16

Similarly:

<$table3>10^2 = 10 * 10 = 100

<$table3>x^4 = x * x * x * x

<$HB>Square Roots

The opposite action to raising a number to a power is called rooting a number. The only type of rooting used in this book is square rooting, which has the opposite effect to raising a number to the power of 2. An example of this is shown below. Note that the BASIC SQR syntax is used to denote square rooting in this book.

SQR(64) = 8 (because 8^2 = 8*8 = 64)

The conventional use of the BASIC MOD operator is for finding the remainder after integer division has been performed. However, it is also very useful for keeping numbers within certain ranges without giving adjacent numbers the same value. This technique is used, for example, in Mandelbrot and Julia programs when converting iteration numbers of unknown range to the 16 colour range of the Amiga’s non-interlaced high resolution screen mode.

An everyday use of MOD can be found in the display on a 24 hour digital watch. The part of the display showing hours is incremented every hour, on the hour, but when the end of the 23rd hour occurs (at 23:59:59) the hour value is set back to zero, from where the process begins again. The hour value is said to be modulus 24 because it has 24 possible values (0 to 23 inclusive). This modulus solution must be used here in order to prevent parts of the time from becoming too large to handle. The only alternative is to stop the hour value when it gets to 23, which would be equally unworkable.

<$fc>Figure B.3: 24-hour clock face showing the action of MOD 24

The 24 hour clock face in Figure B.3 graphically demonstrates a practical example of MOD at work. The hour hand of the clock can rotate an infinite number of times without ever stopping or leaving the range of 0 to 23, but no two adjacent hours ever have the same value.

<$fc>Figure B.4: Four-hour clock face demonstrating MOD 4

The clock face analogy can be used to demonstrate all instances of modulus arithmetic. For example Figure B.4 shows the application of MOD 4. This clock has four possible values, 0 to 3 inclusive. Note that the range always begins at 0, an offset would need to be added to the result if a different base was required. Table B.1 demonstrates the use of the four hour clock by showing the value of a number, x, against (x MOD 4).

<$tc>Table B.1: The action of MOD 4

<$table2>x (x MOD 4)

<$table2>0 0

<$table2>1 1

<$table2>2 2

<$table2>3 3

<$table2>4 0

<$table2>5 1

<$table2>6 2

<$table2>7 3

<$table2>8 0

<$table2>9 1

<$table2>etc. etc.

The following BASIC program can be used to demonstrate the MOD operator (the program will work in both Amiga and GFA BASIC). On each cycle of the WHILE…​WEND loop a variable, x, is incremented and then printed on the screen next to the corresponding value of (x MOD 4).

<$ob>x=0 <$ob>WHILE 1 <$ob> PRINT x,(x MOD 4) <$ob> INC x <$ob>WEND

<$ha>Angles - Degrees and Radians

An angle describes the size of a turn. Angles are usually expressed in degrees, where a full circle consists of 360 degrees, a semi-circle has 180 degrees and so on. However, in Amiga and GFA BASIC the more mathematical radian equivalent is used, where angles are normally expressed in terms of the constant, PI. PI is a common mathematical constant known to BASIC, and is equal to approximately 3.1416.

<$fc>Figure B.5: Common degree to angle conversions

Figure B.5 shows the equivalent degree and radian values for some common angles. In the case of more general values the two equations below can be used to convert between radians and degrees.

<$ob>degree_value = 180 * (radian_value/PI)

<$ob>radian_value = degree_value * (PI/180)

A right angled triangle is one which contains a right-angled (90 degree) corner. An example of a triangle of this type, with the right-angle and hypotenuse marked, is shown in Figure B.6. The hypotenuse is just the mathematical name for the longest side, which can always be found directly opposite the right-angle.

<$fc>Figure B.6: A typical right-angled triangle

<$HB>Pythagorus' Theorem

This simple law states that the square of the longest side of a right-angled triangle (the hypotenuse) is equal to the sum of the squares of the two other sides. Taking the triangle in Figure B.6 as an example we can form the following equation:

c^2 = a^2 + b^2

This only gives the square of c. To find the actual length both sides of the equation must be square rooted:

c = SQR(a^2 + b^2)

<$HB>Simple Trigonometry

There are three useful equations which allow the length of a right-angled triangle’s sides to be calculated from one of its angles and vice-versa. These are shown in Figures B.7a to B.7c.

<$fc>Figure B.7: Application of the three common trigonometrical ratios

Note that opposite is used to refer to the length of the side opposite the angle, A, and adjacent is the length of the non-hypotenuse side which touches the angle. SIN, COS and TAN are mathematical functions, which are built into BASIC. The relevant syntax for these functions is:

<$ob>result = SIN(angle)

<$ob>result = COS(angle)

<$ob>result = TAN(angle)