Mandelbrot on real numbers (new post)

[jehovajah]

I was tired last night so i stopped.

What i did next was to challenge my assumption that the mandy cannot be drawn. This notion was based on some initial research i did into what the hell the mandelbrot set was. The idea ofg a pre image stuck with me which basically meant that the basis set of the function, that is the ingredients of the recipe contain the form of the mandelbrot set and we are only discovering it by a process of elimination. Hence my sculpting analogy. I was thinking of Michaelangelo at the time!

It seemed easier at the time to go with that idea particularly as colouring schemes depended on it.

However the function map "draws" something, i realised and i questioned why it was not the mandelbrot set. What does the recipe actually produce?

Well it ain't spaghetti bolognese

The recipe involves endlessly mixing and cooking so it aint bi-scuits(twice cooked) either

The function maps a set onto itself, so some element s of the set are going to be "hit" at each iteration. If we colour only those within the |z|<2 boundary that get hit we wiil get a circle, so this is why the pre image defines the set. however if we colour those hit by how many times they get hit i felt that a shape akin to the mandelbrot might begin to emerge as the concentration of hits in that area.

I do not think it will be a clear as the mandelbrot, but it should resemble.

So with that idea in mind i set about exploring how to "draw" a rough outline of the mandelbrot using polar coordinate reference frame.

Found some interesting stuff, took time to look at the flowers produced and just gently meanderd about... it was lovely.


So back to you .

Using you information i proposed the following mandelbrot polar process

r(0) =r(0)^2+(-1+cosø), 0<=ø<=2π, r(0) initially =0.

The controls are The integers and ø and the number of iterations.

Play around with this and get back to me.

[jehovajah]

This code by mackc may be able to be modified for the purpose of producing a polar mandy?

http://wonderfl.net/c/A4Om/read



package 
{
    import com.bit101.components.HSlider;
    import flash.display.Bitmap;
    import flash.display.BitmapData;
    import flash.display.Sprite;
    import flash.events.MouseEvent;
    import flash.utils.setTimeout;

    /**
     * Calculating fractional mandelbrot using
     * polar vs cartesian form of complex numbers.
     *
     * Click below slider to zoom in.
     *
     * @author makc
     */
    public class Test extends Sprite
    {
        public var bmp:BitmapData;
        public var pow:HSlider;

        public var x0:Number = 0;
        public var y0:Number = 0;
        public var z0:Number = 100;

        public function Test ()
        {
            addChild (new Bitmap (bmp = new BitmapData (465, 464)));

            // quick test of PolarComplex' add()
            var foo:PolarComplex = new PolarComplex; foo.init (1,  2);
            var bar:PolarComplex = new PolarComplex; bar.init (4, -7);
            foo.add (bar); trace (foo.re (), foo.im ()); // 5, -5

            pow = new HSlider (this, 10, 10, change);
            pow.setSliderParams (2, 3, 2);
            pow.width = 445;
            pow.tick = 0.01;

            render ();

            stage.addEventListener (MouseEvent.CLICK, zoom);
        }

        public function change (whatever:* = null):void {
            setTimeout (render, 100);
            pow.enabled = false;
        }

        public function render ():void {
            doMandelbrot (x0, y0, z0, pow.value, new CartesianComplex, new CartesianComplex);
            doMandelbrot (x0, y0, z0, pow.value, new PolarComplex, new PolarComplex, 232);
            pow.enabled = true;
        }

        public function zoom (whatever:*):void {
            if (mouseY > pow.x + pow.height) {
                var i:int = mouseX;
                var j:int = mouseY % 232;
                var cx:Number = x0 + (i - 232.5) / z0;
                var cy:Number = y0 + (j - 116.0) / z0;
                z0 *= 2;
                x0 = cx;
                y0 = cy;
                change ();
            }
        }

        public function doMandelbrot (centerX:Number, centerY:Number, zoom:Number, power:Number, Z:IComplex, C:IComplex, startY:int = 0):void {
            bmp.lock ();
            for (var i:int = 0; i < 465; i++)
            for (var j:int = 0; j < 232; j++) {
                var cx:Number = centerX + (i - 232.5) / zoom;
                var cy:Number = centerY + (j - 116.0) / zoom;
                C.init (cx, cy);
                Z.init (cx, cy);
                var m:int = 0, n:int = 20;
                while (m < n) {
                    // Z = Z^P + C
                    Z.pow (power); Z.add (C);
                    // bail out?
                    cx = Z.re ();
                    cy = Z.im ();
                    if (cx * cx + cy * cy > 4) break;
                    m++;
                }
                bmp.setPixel (i, j + startY, 0x10101 * int (255 * m / n));
            }
            bmp.unlock ();
        }
    }
}

interface IComplex {
    function init (x:Number, y:Number):void;
    function add (c:IComplex):void;
    function pow (p:Number):void;
    function re ():Number;
    function im ():Number;
}

class CartesianComplex implements IComplex {
    private var x:Number = 0;
    private var y:Number = 0;

    public function init (x:Number, y:Number):void {
        this.x = x;
        this.y = y;
    }
    public function add (c:IComplex):void {
        this.x += c.re ();
        this.y += c.im ();
    }
    public function pow (p:Number):void {
        var ap:Number = p * Math.atan2 (y, x);
        var rp:Number = Math.pow (x * x + y * y, p / 2);
        this.x = rp * Math.cos (ap);
        this.y = rp * Math.sin (ap);
    }
    public function re ():Number { return this.x; }
    public function im ():Number { return this.y; }
}

class PolarComplex implements IComplex {
    private var a:Number = 0;
    private var r:Number = 0;
   
    public function init (x:Number, y:Number):void {
        a = Math.atan2 (y, x);
        r = Math.sqrt (x * x + y * y);
    }
    public function add (c:IComplex):void {
        // I have no magic formula
        // so let's do it hard way
        var ax:Number = re ();
        var ay:Number = im ();
        var bx:Number = c.re ();
        var by:Number = c.im ();
        // c = a + b
        var cx:Number = ax + bx;
        var cy:Number = ay + by;
        // r = |c|, but normalize a 1st
        ax /= r;
        ay /= r;
        r = Math.sqrt (cx * cx + cy * cy);
        // rotate a 90° left and store in b
        bx = -ay;
        by = +ax;
        // transform c into basis a, b
        var dx:Number = cx * ax + cy * ay;
        var dy:Number = cx * bx + cy * by;
        // finally, calculate new angle
        a = a + Math.atan2 (dy, dx);
    }
    public function pow (p:Number):void {
        a = a * p;
        r = Math.pow (r, p);
    }
    public function re ():Number { return r * Math.cos (a); }
    public function im ():Number { return r * Math.sin (a); }
}

[jehovajah]

These were created in grapher on the mac, but the programme is buggy. Curvuspro is available as a free download and easier to interact with.


These polynomial expressions of the mandy iteration for polar coordinates are for research, so change anything to explore what happens.

[jehovajah]

       public function doMandelbrot (centerX:Number, centerY:Number, zoom:Number, power:Number, Z:IComplex, C:IComplex, startY:int = 0):void {
            bmp.lock ();
            for (var i:int = 0; i < 465; i++)
            for (var j:int = 0; j < 232; j++) {
                var cx:Number = centerX + (i - 232.5) / zoom;
                var cy:Number = centerY + (j - 116.0) / zoom;
                C.init (cx, cy);
                Z.init (cx, cy);
                var m:int = 0, n:int = 20;
                while (m < n) {
                    // Z = Z^P + C
                    Z.pow (power); Z.add (C);
                    // bail out?
                    cx = Z.re ();
                    cy = Z.im ();
                    if (cx * cx + cy * cy > 4) break;
                    m++;
                }
                bmp.setPixel (i, j + startY, 0x10101 * int (255 * m / n));
            }
            bmp.unlock ();
        }
    }

The bits in green i do not understand yet. The orange bit i do not understand if it is colouring the initial point relative to the iterated point at break, or the iterated point relative to the initial point at break.

In any case Z.pow (power) needs to be looked at in a bit of detail.

[jehovajah]

interface IComplex {
    function init (x:Number, y:Number):void;
    function add (c:IComplex):void;
    function pow (p:Number):void;
    function re ():Number;
    function im ():Number;
}


This defines IComplex as an interface but i do not understand what that means.
IComplex is then called in a class designation, but also recursively in its definition?
.

Or maybe the interface defines IComplex and the designations are for information to the reader only,or rovide a meta data linking the class and the interface. I don't understand! Is it some kind of container? it seems to allow a variable or a structure or a construct object to take a pointer.


class CartesianComplex implements IComplex {
    private var x:Number = 0;
    private var y:Number = 0;

    public function init (x:Number, y:Number):void {
        this.x = x;
        this.y = y;
    }

Part one of the interface.


   
public function add (c:IComplex):void {
        this.x += c.re ();
        this.y += c.im ();
    }

Part 2 of the interface,


    public function pow (p:Number):void {
        var ap:Number = p * Math.atan2 (y, x);
        var rp:Number = Math.pow (x * x + y * y, p / 2);
        this.x = rp * Math.cos (ap);
        this.y = rp * Math.sin (ap);
    }
    public function re ():Number { return this.x; }
    public function im ():Number { return this.y; }
}

Part 3 of the interface.

class PolarComplex implements IComplex {
    private var a:Number = 0;
    private var r:Number = 0;
   
    public function init (x:Number, y:Number):void {
        a = Math.atan2 (y, x);
        r = Math.sqrt (x * x + y * y);
    }

This is a repeat of part 1 of the interface for polar complex forms.


    public function add (c:IComplex):void {
        // I have no magic formula
        // so let's do it hard way
        var ax:Number = re ();
        var ay:Number = im ();
        var bx:Number = c.re ();
        var by:Number = c.im ();
        // c = a + b
        var cx:Number = ax + bx;
        var cy:Number = ay + by;
        // r = |c|, but normalize a 1st
        ax /= r;
        ay /= r;
        r = Math.sqrt (cx * cx + cy * cy);
        // rotate a 90° left and store in b
        bx = -ay;
        by = +ax;
        // transform c into basis a, b
        var dx:Number = cx * ax + cy * ay;
        var dy:Number = cx * bx + cy * by;
        // finally, calculate new angle
        a = a + Math.atan2 (dy, dx);
    }

This is the repeat of part 2 and the part that relates to possible programming of the polar mandy,


    public function pow (p:Number):void {
        a = a * p;
        r = Math.pow (r, p);
    }

This is a repeat of part 3 of the interface for polar complex.


    public function re ():Number { return r * Math.cos (a); }
    public function im ():Number { return r * Math.sin (a); }


For the polar mandy i think i would need to develop part 2 of the interface by adding a new class in line with Kali's and Ken's definitions of what is going on in the mandelbrot on the reals, but introducing the polar mandy distinctions.

I did a quick search and found this

in which it is revealed that Benoit worked with polar coordinate but he kept theta set at a fixed value and recursively defined r. Thus i have been exploring a more general case than he initially did!

<iframe frameborder="0" scrolling="no" style="border:0px" src="http://books.google.com/books?id=As2xeIwS6OgC&lpg=PA206&ots=lBXb_jDRqD&dq=polar%20mandelbrot&pg=PA10&output=embed" width=500 height=500></iframe>

[jehovajah]

This is another relation to keep you going  while i think on!
This is only 3 iterations but manages to keep between 1 and -2 on the ±(r,0) radials, while zooming elsewhere.

[jehovajah]

interface IComplex {
    function init (x:Number, y:Number):void;
    function add (c:IComplex):void;
    function pow (p:Number):void;
    function re ():Number;
    function im ():Number;
}


This defines IComplex as an interface and i think it means that a kind of "structure" of pointers is set up. This structure is a higher level form of struct or union or class. This allows classes to be gathered into a structure and pointers in a recursive call.


IComplex is then used in a class designation. This recursive definition
is only possible through pointers

The interface defines IComplex and the designations are   linking the classes and the functions to the interface. i am guessing! Is it some kind of container? it seems to allow a variable or a structure or a construct object to take a pointer.

What follows is one implementation for Icomplex
class CartesianComplex implements IComplex {
    private var x:Number = 0;
    private var y:Number = 0;

    public function init (x:Number, y:Number):void {
        this.x = x;
        this.y = y;
    }

Part one of the interface.


   
public function add (c:IComplex):void {
        this.x += c.re ();
        this.y += c.im ();
    }

Part 2 of the interface,


    public function pow (p:Number):void {
        var ap:Number = p * Math.atan2 (y, x);
        var rp:Number = Math.pow (x * x + y * y, p / 2);
        this.x = rp * Math.cos (ap);
        this.y = rp * Math.sin (ap);
    }
    public function re ():Number { return this.x; }
    public function im ():Number { return this.y; }
}
Part 3 of the interface.

This implementation returns x and y to the instance of icomplex. That means that the software arrangement that has been programmed by the author defines an "object" with attributes. When the main function pulls it all together the programmer can choose an example of the "idea"  of the object or "objects" . These objects are like ghosts in the machine and by naming one of them they appear with all the attributes given to them.  This naming is called instancing.

The programmer wanted to be able to use common mathematical "language"  so the instances would look and behave like  mathematical ideas called complex numbers. The class definition or declaration really pulls together all the essentials of a complex number, and shows how convoluted the idea is!

We may tend to claim these ideas are basically simple, but the programming hoops that are involved in the idea show the convoluted complexity.

 What follows is a second implementation of Icomplex

class PolarComplex implements IComplex {
    private var a:Number = 0;
    private var r:Number = 0;
   
    public function init (x:Number, y:Number):void {
        a = Math.atan2 (y, x);
        r = Math.sqrt (x * x + y * y);
    }

This is a repeat of part 1 of the interface for polar complex forms.


    public function add (c:IComplex):void {
        // I have no magic formula
        // so let's do it hard way
        var ax:Number = re ();
        var ay:Number = im ();
        var bx:Number = c.re ();
        var by:Number = c.im ();
        // c = a + b
        var cx:Number = ax + bx;
        var cy:Number = ay + by;
        // r = |c|, but normalize a 1st
        ax /= r;
        ay /= r;
        r = Math.sqrt (cx * cx + cy * cy);
        // rotate a 90° left and store in b
        bx = -ay;
        by = +ax;
        // transform c into basis a, b
        var dx:Number = cx * ax + cy * ay;
        var dy:Number = cx * bx + cy * by;
        // finally, calculate new angle
        a = a + Math.atan2 (dy, dx);
    }

This is the repeat of part 2 and the part that relates to possible programming of the polar mandy,


    public function pow (p:Number):void {
        a = a * p;
        r = Math.pow (r, p);
    }

This is a repeat of part 3 of the interface for polar complex.


    public function re ():Number { return r * Math.cos (a); }
    public function im ():Number { return r * Math.sin (a); }
}

This implementation returns rcosa and rsina.

You can't have an implementation without a configuration of the hardware. And you can't have a configuration without the hardware!  So starting with hardware we surprisingly talk about these physical things in abstract terms! General terms that encompass all possibilities. It is no wonder we get a little stressed with computer programming!

So what is missing is an infrastructure for plotting polar coordinates, an interface for representing polar coordinates, and a class declaration of polar coordinates.

For the Polar mandy exploration i think i would need to develop part 2 of the interface by adding a new class  called Reals in line with Kali's and Ken's definitions of what is going on in the mandelbrot on the reals, and then introduce the polar mandy class.

[jehovajah]

Seems rather obvious now, but i have to point out that the parameters of the reference frame, despite there relationship, are entirely independent. Thus r does not have to be defined in terms of theta, nor does x have to be defined in terms of y.

To obtain Kali's plots we simply plot the first function against the second, but to do this we could need a common parameter and thus a parametric representation.

Parametric representation means effectively 2 or more reference frames can be combined to form any set of reference frames we can construct.

Commonly we use a single origin to establish a reference frame in a model. However in reality we need to use as many origin centres as necessary to describe the motion in focus. For example a Fibonacci spiral could be described by 2 centres of rotation superimposed: one describes the type of parabolic curve the other describes how that parabolic curve spirals.

However, useful as parametric relations are they do  restrict the independence of the reference frames, as any measure along these frames are not in general linked to each other , but they are linked to the transformations of the reference frames.

[jehovajah]

These are parametric and can be independently varied. This particular form shows what happens to points on  curve after itereation 4 times. The curve is specified by .

Trig functions are used to keep the initial input values between 1 and -2

[jehovajah]

The conception is clear to me now. We need only to define a class called the reals. Then using exactly two reals as Kali does we need to plot them not on a pair of orthogonal axes, but on a set of generalised axes such as we call polar coordinates.

Therefore we simply set r= f(x) and = f(y) exactly as Kali prescribes. The polar plot of these functions is what I am after so I just need to alter the plotting call to plot in this way.

[jehovajah]

It suddenly seems clear to me that to plot (r,) on a pixelated screen i am going to have to use x,y coordinates for screen position! Thus if r_n= r_n-1^2+r₀, and for some suitable ranged function for then

x=r_n*cos
y=r_n*sin

or if f(x), f(y) are Kali's mandelbrot  functions on the reals, form f(r),f(); that is perceive Kali's functions as implicit functions of the radius independent of the implicit function of the angle.

Then
x= f(r)*cos (f()
y= f(r)*sin (f().

Now, if we want to really "mess" about we could use 2 (r,)'s and form r as a parametric equation in t, or functions of phase shifted.

(r₁,)= (sin(t),cos(t))

(r₂,)= (t²+sin(t),cos(t)-1).

These are then iterated and the results plotted (r₁,r₂) for cartesian plot or (r₁*cos(r₂),r₁*sin(r₂)), for a polar plot. We can form many combinations for the plots, to explore what results..

[jehovajah]

Based around code by makc.


interface Kalireal {
    function init (x:Number, y:Number):void;
    function add (c:Kalireal):void;
    function pow (p:Number):void;
    function re ():Number;
    function re2 ():Number;
}

This hopefully saves rewriting too much code.


class CartesianKalireal implements Kalireal {
    private var x:Number = 0;
    private var y:Number = 0;

    public function init (x:Number, y:Number):void {
        this.x = x;
        this.y = y;
    }
    public function add (c:Kalireal):void {
        this.x += c.re ();// not sure what this means
        this.y += c.re2 ();//
    }
    public function pow (p:Number):void {
/*this function converts to polar so that raising to a power can be performed for a complex number so i need to check it for appropriateness for real exponetiation. it then converts back to be able to print on screen. The polarmandy would just do this second part at this stage.*/
        var ap:Number = p * Math.atan2 (y, x);
        var rp:Number = Math.pow (x * x + y * y, p / 2);
        this.x = rp * Math.cos (ap);
        this.y = rp * Math.sin (ap);
    }
    public function re ():Number { return this.x; }
    public function re2 ():Number { return this.y; }
}


This is a rough conception that will need modifying to work "proper".



class PolarKalireal implements Kalireal {
    private var a:Number = 0;
    private var r:Number = 0;
   
    public function init (x:Number, y:Number):void {
        a = x;
        r = y;
    }
    public function add (c:Kalireal):void {
     this.x += c.re ();// not sure what this means
        this.y += c.re2 ();//   
    }
    public function pow (p:Number):void {
        a =a*p;
        r = Math.pow (r, p);
    }
    public function re ():Number { return r * Math.cos (a); }
    public function re2 ():Number { return r * Math.sin (a); }
}

TBC. further revision required.

[jehovajah]

 
    public function init (x:Number, y:Number):void {


The iterators or loop  variables represent our ability to move through the plane and to record our position in the plane by cartesian coordinates. In this case they are analogous to screen coordinates and we can translate them to pixel position.
But now we want to translate them to a distance from the origin and an angle from the horizontal, we draw a right angle triangle and derive
a = Math.atan2 (y, x);
        r = Math.sqrt (x * x + y * y);
[Because i am starting with the polar coordinates i can just write
        a = x;
        r = y;]
   
So now every position in the plane can be moved through and recorded by iterators a and r, instead of x and y.

However instead of writing code using the idea ofa and r, we elect to retain x and y and translate., for some ueful reasons i might add.

Now if i were defining addition in couples i would make it straight forward and what we call vecctorlike addition

(a,r) +(a,r)=(2a,2r) etc but we put a constraint on what we do: whichever system we use must produce the same geometry!
Why?

Now to tackle the constraint we have to model addition in cartesian using the coordinates in polar. Clearly we cannot expect the different motion freedoms to exactly the same and so we expect some translation as before. We use the right triangle like a coder and decode between the two systems.
 
    public function add (c:Kalireal):void {
        // I have no magic formula
        // so let's do it hard way
  makc earlier defined a cartesian add which he could actually call here:
        var ax:Number = re ();
        var ay:Number = re2 ();
        var bx:Number = c.re ();
        var by:Number = c.re2 ();
        // c = a + b
        var cx:Number = ax + bx;
        var cy:Number = ay + by;

Makc now proceeds to do the translation to cartesian from polar! But first he has to get the polar conversion code that applies to each position, which is given in cartesian form to start with!

        // r = |c|, but normalize a 1st
He already has r for every position, which he obtains by initialisation, and he has a by the same process.
however he does not have the ratio form of the sine and cosine functions. So he decides to implement the ratio forms for this "complex number" which is calling the add method

        ax /= r;/*do not understand this code*
        ay /= r;/*

But why does he set the r equal to c? or rather how does this code set the radius equal to the radius of c?
 
        r = c;/*to here*/


He needs the radius of the result to translate the polar version back to the cartesian version. But he already has the cartesian version. Could thiss be the necessary update of r?
 
He now sets up a  dot product  multiplication between c and the trig ratios  for this "complex number"  and c and this complex number rotated
       // rotate a 90° left and store in b
        bx = -ay;
        by = +ax;
        // transform c into basis a, b
        var dx:Number = cx * ax + cy * ay;
        var dy:Number = cx * bx + cy * by;
 This he indicates translates c into a vector over the basis of these unit vectors a,b which are orthogonal by design, and out of phase by a rotation  of π/2  .


So by this stage he has updated r and now he can update a   

// finally, calculate new angle

        a = a + Math.atan2 (dy, dx);
    }

This code seems to illustrate the convoluted nature of translating cartesian addition into polar representation. In fact, nowhere is polar addition exhibited. What we see is cartesian addition with the result converted to polar.

I wonder then if it would not be possible to call cartesian add, and then call polar init for the new result?

In any case we have a clear example of how "chaos can arise out of order"!

Because i do not want to model cartesian vector addition, but to look at purely polar interaction i have to define a new polar addition , which is very simple.

I have also looked at the power method, and again this does not require conversion so i have modified it for another purpose, but it is experimental at this stage.

The idea now is to work toward the design constraints Kali sets out.

[jehovajah]

I have considered this topic further in the light of competing vector algebra ideas and explained it in my blog


z(x,y)= (r²-ø²)cos(2rø)+i*(r²-ø²)sin(2rø) + c(x0,y0}= x + iy + c

The above is the polar mandelbrot which is intrinsic to a spherical system.

[jehovajah]

I have spent a confusing time learning about relationships in Quasz, and in general.

The bailout conditions are still a wonder to me, as there are several different possibilities, logical comparisons included, and results that show the parser attempting to make sense of any typing errors!. Every time i think i have an inkling i forget something and have to re-look at it. It is a sign of unfamiliarity with relational calculus, intuitive geometrical interpretation and the "damned negative image" of a sculpted form.

Any way it will do me good to seek the essentials of relations, as Hamilton demonstrates their fundamental importance to all vector/tensor algebras, especially in revealing the trigonometric basis of them all.

In the case of Quasz the real and imaginary parts are initiated from a standard "for loop" instruction, but then are variable according to the actions performed on the quaternion they are a part of. If the vectors i,j or k are missed out the resulting image still reflects the attachments of the coefficients( real, imaginary, ...) because the for loop structure preserves this relationship in oder to define a block of quaternions. The vectors only become necessary for the variable case where they serve as identifiers for combination and summation, and the app has functions that do this automatically, with the inbuilt quaternion algebra.

To override the inbuilt assignment the coefficients have to be "multiplied" that is attached to the required vector manually. To visualise what this means graphically is where i struggle, and so i run several experimental versions to get a "feel".

The mandelbrot is a relationship between the real coefficient and the imaginary coefficient, but it turns out, also between the for loop structure. So the for loop structure is a meta pattern that has to be acknowledged to understand how the mandelbrot works. It is no just the formula. It is also the for loop subsection within which the formula is evaluated. That equates to spatial disposition of the interacting factors and is akin to "action at a distance" considerations .

Within Quasz and possibly within space, attributes within the same boundary surface ,ie plane, effect each other differently to attributes in different boundary surfaces interacting, at least in terms of the re-presentation of the data. The re-presentation of the data is according to the tool chosen and thus says more about the tool than my experience in space. Familiarity with the tool in all its applications is therefore necessary to divine the correct "meaning" of any output.

I progress as i hope the picture will show.

The polar mandelbrot from the rear.