Register to reply 
Rendering the Feigenbaum tree 
Share this thread: 
#1
Mar1311, 11:51 AM

P: 68

Hello. I am attempting to render the bifurcation diagram of the logistic difference equation in C with OpenGL. I think the math behind it is simple enough, but for some reason I am ending up with a structure that resembles the tree but doesn't look quite like it. I would really appreciate it if someone could point out where I am going wrong. Here is how it should look like:
http://brain.cc.kogakuin.ac.jp/~kana...aos/e/BifArea/ http://planetmath.org/encyclopedia/F...umFractal.html The following program produces the output attached to this post. As you can see, you can distinguish that the structure seems to be correct.



#2
Mar1311, 01:06 PM

Engineering
Sci Advisor
HW Helper
Thanks
P: 6,948

I think you are only displaying the data point for the last iteration.
Print out say the last few iteration values in the datapoint array, in each call to calculateplot(). When k is below 3, you will find they are all the same. Then, they start to flip between 2 diffeent values. Then they go round a cycle of 4 different values, then 8, etc. Later on, they are chaotic. Later still they will repeat in cycles with other lengths, like 6 and 3. You need to plot all the different values to make the complete graphic. One way is to calculate say 1000 iterations, to wash out the effect of your choice of a starting value, and then plot say the next 100 iterations. Many of the 100 plotted points will lie on top of each other, but that doesn't matter. 


#3
Mar1311, 02:04 PM

P: 68

Take a look at this:
This is the rendering procedure, which is relatively simple. Note, right now for each k being tested the x value for each point is k itself, and only y varies. And so you would expect to see a vertical line for each k, with the points between dataPoints[set][0] and dataPoints[set][NUM_OF_ITT1] being transient states. Therefore those points are not rendered here. However, that data is still available and can be rendered. Indeed originally it was rendered, but I saw only vertical columns connecting the top outline and the bottom outline. So I simply decided to omit those points from rendering. The mechanism of rendering is simple: We loop through all the sets (the data for all the k's tested) and render a line strip using the first point calculated. Then the same procedure is repeated, rendering the last data point in the array for each set.



#4
Mar1311, 02:17 PM

Mentor
P: 21,215

Rendering the Feigenbaum tree
Minor points
Why is NUM_OF_ITT defined as a floating point value?
BTW, iteration doesn't have any double t's in it, which makes NUM_OF_ITT a bit more difficult to understand than it needs to be. 


#5
Mar1311, 02:31 PM

P: 68

In any case, you can be rest assured that neither of the aforementioned minor programming inconveniences are the cause of the issue. Do you have any other ideas :) ? 


#6
Mar1311, 02:46 PM

Mentor
P: 21,215

I wasn't able to open the first link you posted. I was able to open the planetmath.org link, however.
Another (and clearer, IMO) explanation that seems closer to what you're trying to do is here: http://mathforum.org/advanced/robertd/bifurcation.html The bifurcation graph represents the results of repeated calculating [itex]\mu[/itex]x(1  x) for values of [itex]\mu[/itex] and x. (You're using k for [itex]\mu[/itex] and y for x.) It works by picking a value of [itex]\mu[/itex], and a starting value of x. The next value of x is obtained by substituting it into the expression [itex]\mu[/itex]x(1  x). For some values of [itex]\mu[/itex] the iterated values converge to a specific number. For example, if [itex]\mu[/itex] is 2 and we start with x = .25 and calculate 2*.25*.75, the next x value will be .375. Putting this value in for x, the next x value will be .46875. After a few steps you get values that keep repeating, .5, .5, .5. So one point on the graph you're trying to get will be (2, .5). Similarly, when [itex]\mu[/itex] is 2.5, the iterations settle down to .6, so another point on the graph is (2.5, .6). For values of [itex]\mu[/itex] from 1 to about 3, iteration produces a single value. For larger values of [itex]\mu[/itex], iteration can produce two values, then four values, then eight values, and so on, and that's what gives you the bifurcations, or forks in the diagram. When [itex]\mu[/itex] is around 3.5, you start to get cycles of four different iterated values, so the bifurcation graph will show four different points for a while. Now maybe you know this or maybe not. Your code doesn't contain may comments, so it's hard to tell what you're doing, particularly with your three dimensional array. It would be nice to have a comment saying what each index in that array represents. 


#7
Mar1311, 03:21 PM

P: 68

I am sorry :( I know it can be a nightmare trying to interpreted undocumented code, so I will try to explain to the best of my abilities what I am doing in the code:
1) Pick some starting x value that is below 1.0. This is xstart in the program (0.1). 2) Pick some K <= 1 <= 4 3) Iterate using a for loop NUM_OF_IT times. In each iteration, use the logistics difference equation to calculate the y value, and store it. This y value will be used in the next iteration. For the first iteration, the y value is calculated as: y = K*xstart*(1xstart). This is stored in the dataPoints array, which has this structure: dataPoints[index for data for some unique K][coordinate pair calculated in the ith iteration] = [k value (constant for this index), y value] 4) Render to the screen This will become clearer when taking a look at the following code:



#8
Mar1311, 04:12 PM

P: 68

I am the biggest idiot in the world. As opposed to drawing lines, I should have simply drawn points. The structure seemed correct because it was. There was simply extra information there. I hope I am making sense. Thanks for the help all. Attached picture + the working source below.



#9
Mar1311, 05:15 PM

Engineering
Sci Advisor
HW Helper
Thanks
P: 6,948

Well, it's not quite right yet, because you have those strange lines from the bottom left hand corner.
They are the points when you "start up" the iteration from x = 0.1, until it settles down. If you change 0.1 to a differrent value (say 0.9) you will get a different pattern of those lines. To get rid of them completely, change the line in drawscene() from for ( unsigned int i = 0; i < NUM_OF_ITT; i++ ) to something like for ( unsigned int i = NUM_OF_ITT/2; i < NUM_OF_ITT; i++ ) to skip over the first points you calculate. 


#10
Mar1311, 05:17 PM

Engineering
Sci Advisor
HW Helper
Thanks
P: 6,948




#11
Mar1311, 06:28 PM

Mentor
P: 21,215




#12
Mar1411, 05:22 AM

P: 68

The strange thing is, the site was working perfectly when I made the first post. It stopped responding very soon after.



Register to reply 
Related Discussions  
The Feigenbaum map  Advanced Physics Homework  0  
Feigenbaum number in other fundamental constants  Linear & Abstract Algebra  0  
Lightning strikes tree. Energy is absorbed by tree. Sap evaporates. How much sap?  Advanced Physics Homework  4 