Talk:Mandelbrot set

Continuous coloring

The "equations" in the subsection Mandelbrot Set#Continuous (smooth) coloring are actually not equations since there are no equals signs! Thus, it is not clear which quantity should be equal to the expressions shown there.--SiriusB (talk) 08:24, 26 August 2008 (UTC)

You are right - they are formulae, not equations. I have fixed the text. The formulae associate a real number with each point z in the complex plane outside of the Mandelbrot set. This real number can then be linked to a colour gradient in order to colour the pixels in an image. The algorithm does not seem to be prescriptive about exactly how a colour is derived from a real number value. Presumably the algorithm just ensures that points close to one another have similar real number values, so that colour varies "smoothly", avoiding artificial "contours" where one colour changes abruptly to another. Gandalf61 (talk) 10:30, 26 August 2008 (UTC)

I've taken a closer look on these formulas and I am more convinced than before that they are incomplete. What's missing is an detailed and unambiguous description which values have to be inserted. The most important issue is that the formulas are obviously discontinuous since they invoke the non-smooth n values. The fraction without the n is related to the absolute value, |z|, it is radial symmetric, i.e. yields equal values for equal distances from (0,0). The addition of the iteration number adds a discontinuous component that will far from being smooth, e.g. there may be z1 and z2 with |z1|=|z2| but n1!=n2. Unless one manages to get non-integer n these formulas appear to be useless in the posted forms. However, if one already has non-integer ("smooth") values for n there would be no need for an additional formula (but for another clever algoritm that gives us smooth iteration numbers).--SiriusB (talk) 13:43, 4 November 2008 (UTC)

After taking an even closer look on them and their source, I have found (and now fixed) the error. z should be replaced with z_n, i.e. not the starting point of z but its final value. Therefore both parts of each formula are no longer independent. However, it remains to show that the resulting real-valued function of z is really continuous.--SiriusB (talk) 14:13, 4 November 2008 (UTC)

Finally, I've added a symbol $\nu$ for the smoothed value to turn the naked formulas into proper equations. Someone might feel that this edit might be original "research", but at least it is what the author of the cited source seems to expect from the reader.--SiriusB (talk) 14:21, 4 November 2008 (UTC)

In addition: I have tested the algorithm in a self-written Mandelbrot program. As expected, the smoothing function is not continuous. However, the jumps that occur at the classical color borders become small if, as suggested in the article, several extra iterations are done, so that the result looks smooth. However, I do not know whether the article may benefit from this since this would clearly qualify as original research, I think.--SiriusB (talk) 08:29, 8 November 2008 (UTC)

SiriusB please explain what you meant by maganes which is not an english word. Cuddlyable3 (talk) 12:54, 8 November 2008 (UTC)

It seems likely that maganes is a simple typo for manages - Unless one maganes manages to get non-integer... 216.241.205.81 (talk) 19:23, 20 December 2008 (UTC)

Oops, sorry, I missed that. Yes, its just a typo. Although it might disrupt the continuity of this thread, I've fixed it now ;-)--SiriusB (talk) 10:00, 23 December 2008 (UTC)

I've just made a fairly clumsy tweak to the simplified formula. I adjusted the base of the inner log rather than the constant before the minus because it would have resulted in an irrational number and in all likelihood a base-two log could be used anyway. Somebody may want to check it; I observed the problem not by thinking hard, but by plotting the functions in gnuplot and then tweaking the values until they made more sense -- specifically, that they run from 1 to 0 between bailout and bailout-squared.

What's not made clear in that section is what the function actually does. Here's my mathematical-halfwit attempt:

If we ignore the $+c$ part of the iteration formula, then the we know that the final length of $z_{n}$ at bail-out will be between $B$ and $B^{2}$. We can take our fractional component of the iteration count as an interpolation along this range -- the nearer to $B$ we landed, the closer we came to needing another iteration to escape and the higher the fractional part should be. Evidently one log gives us a linear distance between iterations, and another log gives us a curve that more closely resembles the curve we see in the integer part of the escape time.

Bringing $c$ back in, $z_{n}$ can be anywhere between $B$ and $B^{2}+|c|$, and our fractional part could spill outside of the [0,1] interval. The idea of running on a few extra iterations or using a larger bailout is simply to make the over-spill introduced by $c$ proportionally smaller such that it can be ignored. I think this explains why "If iterations cease as soon as z escapes, there is the possibility that the smoothing algorithm will not work." which is a fairly opaque statement as it stands.

Is any part of that worthy of explanation on the main page? --ToobMug (talk) 16:17, 21 February 2009 (UTC)

Also, my guess is that these extra iterations can be done in comparatively limited precision, because the truncation errors will be small in comparison to values known to be greater than B -- and it's just an approximation for display anyway. I haven't confirmed this yet, and I'm not sure when I'll get around to testing it (yes, I could just think hard -- but I won't). Is it worthy of mention if it's correct? --ToobMug (talk) 16:24, 21 February 2009 (UTC)

Pseudocode error

There seems to be a problem with the pseudocode.

 while ( x*x + y*y <= (2*2)  AND  iteration < max_iteration ) 

Only the first couple pixels will succeed this comparison. At pixel (1,2) for example, the equation will be: (1)*(1) + (2)*(2) <= (2*2), which of course fails the comparison.

151.112.23.68 (talk) 19:21, 29 January 2009 (UTC)

x and y are not pixel counts, they are the horizontal and vertical coordinates of a pixel. The whole M. set is within the range -2<x<1 and -1<y<1 and only your chosen pixel resolution limits the number of pixels within the set. Cuddlyable3 (talk) 21:13, 29 January 2009 (UTC)

I agree, this is very confusing. Maybe the range should be clarified? --xAXISx (talk) 23:34, 7 May 2009 (UTC)

flash mandelbrot set (external)

i stumbled upon this page and i thought it as a good example. It has fantastic zoom but it requires a fast broadband connection.

• [1]

This is a very interesting subject, and if anyone has any more user friendly fractal animations, post them! —Preceding unsigned comment added by 68.209.202.24 (talk) 03:51, 14 February 2009 (UTC)

another external link

I've written another Mandelbrot viewer in Flash: [2] If anyone thinks it warrants inclusion, please add it to the main page. Jamo777 (talk) 17:16, 14 February 2009 (UTC)

Boundaries

What are the extreme values of the real and imaginary components of the points contained in the set? Lucas Brown (talk) 02:25, 22 March 2009 (UTC)

Do you mean root point and apex point ? Informations about boundaries of hyperbolic components :

• 
  boundaries computed with boundary equations
• 
  boundaries computed with Newton Method

--Adam majewski (talk) 06:59, 22 March 2009 (UTC)

What do you mean by "root point" and "apex point?" Lucas Brown (talk) 04:19, 27 March 2009 (UTC)

Root and apex point are points where 2 hyperbolic components meet. (It is not precise definition) WHen you analyse components on real axis then root and apex point are extreme real values for this component.--Adam majewski (talk) 09:15, 28 March 2009 (UTC)

In that case, yes. Lucas Brown (talk) 20:36, 28 March 2009 (UTC)