Welcome to Fractal Forums

Hello. This is Charles Douglas Wehner.

After Benoit Mandelbrot popularized the set of fractal graphics that began with Gaston Julie's work, I also played around with them.

I generalized the idea to what I call "RECURSION MAPS". In the Mandelbrot Set, there is a plane having a real axis and an unreal axis. Each point on that plane therefore has two co-ordinates. The Mandelbrot Set involves a complex addition, and a complex multiplication (using the two co-ordinates). This is repeated until some arbitrary limit is reached - when the numbers get too big, or the count-down expires. An arbitrary colour is chosen for each of the numbers of times that the addition-multiplication was achieved.

However, the Mandelbrot Set, with its addition and multiplication, is just a subset of all recursion maps. I played around, for example, with Euler's GAMMA FUNCTION. I allowed a number to be turned into the gamma of the gamma of the gamma until the process had to stop. This also produced interesting pattern. Unfortunately, I no longer have them.

Putting other functions inside a recursion system should therefore allow a whole new world of machine art to arrive.

I have much to do, and do not know how much I will be able to contribute. However, I will bear it in mind.

As for the images that are already on display - yes! A very high standard for such a new site.

Charles Douglas Wehner

Welcome to the forums Charles!

Welcome

Greetings, and welcome to this particular forum !!!    :D

I would be very much interested in seeing some of your images, if they are available for display on the Internet.
 

Just as I was going to say

You asked to see my results. Tragically, I no longer have them. Those few things I have are standard Mandelbrot - and not up to "Forum Standard".

However, there is a contribution I can add.

You may have heard that Arthur C. Clark, who invented the geostationary broadcasting satellite and wrote "2001, a Space Odyssey", made Mandelbrot images that were ANIMATED. The fine detail sparkled when the colours changed.

This, and other variants on the theme of animation can be accomplished with a simple DOS tool.

I give it away here: http://www.wehner.org/tools/animate

Thousands of people have already fetched it over the years. However, I have not seen any "Fractal Movies" apart from those of Clark.

Charles

www.ultrafractal.com
http://video.google.co.uk/videosearch?q=fractals
http://video.google.co.uk/videosearch?q=flame+fractals

There are lots of animations around.

alan2here wrote "There are lots of animations around".

Fair comment. However, as a newbie I had not properly explored the forum to see what is available. I remembered the Clark images, but had not seen more.

It still does not alter my offer of free GIF animation software (for IBM DOS) at http://wehner.org/tools/animate

Sometimes an animated piece of art can be used for "corporate image" on a website. GIF has been around for so long, that all modern browsers support it.

Charles

Charles Douglas Wehner wrote:
>
>    You asked to see my results.  Tragically, I no longer have
>    them.  Those few things I have are standard Mandelbrot -
>    and not up to "Forum Standard".

Yes, that is too bad you no longer have them.  I guess the enjoyment now will be to explore some of the fractal applications now available (there are many which are FREEWARE) and try creating something new for yourself.

>
>    You may have heard that Arthur C. Clark, who invented
>    the geostationary broadcasting satellite and wrote "2001,
>    a Space Odyssey", made Mandelbrot images that were
>    ANIMATED.  The fine detail sparkled when the colours
>    changed.

Yes, I have both a VHS and a DVD copy of the video that gets shown every now and then on the Public Broadcasting Stations:  "Fractals: The Colors of Infinity" (1997).  This 52-minute video has Dr. Arthur C. Clarke chronicling the 1980 discovery by Dr. Benoit Mandelbrot.  Clarke explores this discovery's impact on the world of mathematics (fractal geometry) - with the help of Dr. Mandelbrot, Prof. Stephen Hawking, Dr. Michael Barnsley and Prof. Ian Stewart.  It is set to a musical score by David Gilmour of the rock group Pink Floyd, and has vibrant computer graphics to help the audience visualize the M-set and illustrate its infinite complexity.

>
>    .....a simple DOS tool.   I give it away here:
>      http://www.wehner.org/tools/animate/ (http://www.wehner.org/tools/animate/)

Thank you for making this tool available to everyone that reads this Forum !!

That was a very informed comment on the "Colors of Infinity".

Fifteen to twenty years ago, I wrote a Qbasic program which I called "Almondbread" - an English translation of the word "Mandelbrot" (har, har, har).

It displayed in QVGA (320 by 240), by plotting two dots to the same place on screen, and two rows to each row. The colours were limited on screen, but one could see the pattern. The file on disk was VGA (640 by 480), and 256 colours. The starting co-ordinates and a number such as 0 or 1 were dumped into the picture area (bottom left) to keep a record.

When the BMP file (which I renamed as something like MBM -Mandelbrot bitmap) was loaded into Almondbread, a small cursor of 32 by 24 dots on screen (negative video) appeared. This could be moved with the arrow keys, and ENTER could be pressed. Almondbread would now make a tenfold enlargement of the chosen area. That, in turn, could be used for a hundredfold enlargement and so on. All because of the few corrupted bytes carrying the parameters.

One could, of course, make another enlargement just one screen-dot out of place, and then join images together so that even the corrupted bytes were covered.

This was the tool I used for the Gamma-function images. It was very, very slow - particularly with the slow processors of those times. Often, like most fractal enthusiasts, I would leave the computer running for weeks. However, being Basic, it allowed any mathematical function to be put inside the recursion loop. There was even a Quick-Basic compiler that was Qbasic compatible, so if I had got myself the compiler I could have made a stand-alone EXE.

Last night (Sunday, 15 October 2006) I tried out FRACTINT. This is because I do not want to "reinvent the wheel". I also searched my belongings in the hope of finding Almondbread. No luck yet.

For years I have been toying with the idea of making a high-speed RECURSION LANGUAGE that would run in fixed-point, and accept polynomials. The general idea is that a script would be written (TEMPLATE.REC or PROGRAM.REC), and RECURSE.COM would compile into itself the set of machine-code macros (with no CALLS) that would generate the image. Because I have limited tools, it would have to be a DOS command - but an icon could be used, and clicked from Windows (as with my LEN, ANNA and other programs). So a window opens for DOS, the program needs no parameters - they are in the template - and then it closes.

I conceived the fractional factorials for three reasons:

(1) When you use a pocket calculator, and input the number 3 followed by the exclamation mark, it gives 6 - the factorial. However, if you input 3, divide by 10 (giving 0.3), multiply by 10 (giving 3) and then an exclamation mark, it says "ERROR". A needless error-halt. This is because 0.3 is 0.0100110011001100110011' in binary and the registers are too small for an infinite sequence. So the number 0.29999999999999 is rounded up and only looks like 0.3. Similarly, 2.9999999999999 only looks like 3. The factorial program will not accept fractions on a calculator, but the "fRactorial" program will.

(2) To integrate X cubed, you divide by 4 and raise the power by 1 - giving one-quarter X to the fourth. To differentiate, you divide by 3 and lower the power by 1, giving 3 X-squared. I changed this to integration by 3!/4! X-to-the-fourth and differentiation by 3!/2! X-squared. They are functionally identical. However, given the fractional factorials one can half-integrate or half-differentiate by plugging in fractional factorials instead of integer factorials. So the processof calculus becomes a continuum - that is my Eucalculus (on my website). Sines and cosines, for example, can be partially integrated or partially differentiated by working on the polynomial.

(3) Factorial 3 is 6. Gamma 4 is 6. Did Euler make a mistake? Why is the Gamma function incompatible with the factorials? On a calculator, one needs two buttons. This does not make sense. I suggested my fractional factorials because they can be used for factorials - even when one has 2.9999999999999 giving  5.9999999999999, and for gamma by taking 4, subtract 1, and do fractorials. Both functions from the same button. These things are used for Bessel functions and the like.

After I published, a mathematician friend said that the Russians are tending to give up gamma in favour of fractional factorials.

There is my information on Euler and the Eucalculus at http://wehner.org/euler and on machine-code mathematics at http://wehner.org/fpoint .

I also explored the Gamma function in the complex plane, as did Weierstrass. Here is a remarkable generalisation:

For any polynomial of the form A + BZ + CZ-squared + DZ-cubed etc., there will be symmetry about the X-axis. This is not just true for Mandelbrot but for all transcendental functions. Just try working out with Z=X+iY and with Z=X-iY the terms Z, Z-squared, Z-cubed etc, and you can see the symmetry.

I was using a Chebychev polynomial in "Almondbread", that polynomial having been created for the range 0 to 3. I could move down or up the X-axis (1.5! is 0.5! times 1.5) but not up or down the imaginary Y. So the special polynomial made this possible.

I remember the images. There were five regions in the plane where "blobs" appeared. I may yet try to recreate them.

Charles

Charles Douglas Wehner wrote:
>
>    Fifteen to twenty years ago, I wrote a Qbasic program
>    which I called "Almondbread"....

The name is very familiar to many, since I believe it has been used by other people in creating fractal generators.  One of them was a Michael R. Ganss <ganss@novedia.de (ganss@novedia.de)> <rms@cs.tu-berlin.de (rms@cs.tu-berlin.de)> that made one for running on UNIX systems, though I am not sure his website is still active:  http://www.cs.tu-berlin.de/~rms/AlmondBread/ (http://www.cs.tu-berlin.de/~rms/AlmondBread/)
But it is still available here:  http://www.Nahee.com/spanky/pub/fractals/programs/unix/almondbread-0_22_tar.gz (http://www.Nahee.com/spanky/pub/fractals/programs/unix/almondbread-0_22_tar.gz)

Also, Michael Bhnisch wrote a program for Amiga systems called "Apfelkiste" using both C and Assembler.

>
>    Last night (Sunday, 15 October 2006) I tried out FRACTINT.
>    This is because I do not want to "reinvent the wheel".

Did you get the latest Developer's version from:  http://www.FractInt.org/ (http://www.FractInt.org/)
This would be the 20.4.04 version level.

>
>    I also searched my belongings in the hope of finding
>    Almondbread.   No luck yet.

Well, I wish you luck if you pursue your search.  It would be interesting to see what you had written back then.

>
>    I was using a Chebychev polynomial in "Almondbread",
>    that polynomial having been created for the range 0 to 3.
>    I could move down or up the X-axis (1.5! is 0.5! times 1.5)
>    but not up or down the imaginary Y.  So the special
>    polynomial made this possible.

Before you get really involved with using FractInt, you may wish to download some of the various .FRM (forumla files) that have been collected into a single large file:  
    http://www.Nahee.com/PNL/OrgForm.html (http://www.Nahee.com/PNL/OrgForm.html)
There are several interesting Chebychev formulae to be found.

>
>    I remember the images.  There were five regions
>    in the plane where "blobs" appeared.  I may yet try
>    to recreate them.

Looking forward to whatever you find and/or create.    :)

Nahee_Enterprises wrote:

>  The name is very familiar to many, since I believe it has been
>  used by other people in creating fractal generators.

Yes, today, everybody will know the name of Mandelbrot - and many will have translated it to other languages such as to "Amandepain" in French (what a painful joke).

>  http://www.cs.tu-berlin.de/~rms/AlmondBread/

You were right. That address has gone. The Technical University is now at http://iv.tu-berlin.de/ but the rms/Almondbread file is not there. The other address does download a Zip file though. It is 406,431 bytes.

>  "Apfelkiste"

Apple crate.

>  Did you get the latest Developer's version from:  http://www.fractint.org/
>  This would be the 20.4.04 version level

I got Version 20 - advertised as the latest, but did not study the suffices. Because of the "learning curve" problem - spending too much time learning the details of other peoples' tools - I may give up on it. The program crashed after every file I made, so I had to reload it every time. The results were much like my own, many years ago. However, such things as cycling through the colours (spectacular) are features I myself never programmed (no time). There was an impressive list of contributors. However, I am not sure that every possible kind of fornula may be entered.

So I am thinking of starting from absolute basics - writing in assembler from "ground zero".

I spent several hours looking for the old program last night (again), but have decided to give up. Assembler it has to be.

>  Before you get really involved with using FractInt, you may wish to download
>  some of the various .FRM (forumla files) that have been collected into a single large file: 

Yes, I have my own formulae at http://wehner.org/fpoint - however, I will be examining this site carefully because it may give me clues as to whether FRACTINT can be programmed the way I want. I like the bizarre fractal background of that page - very chintzy.

Charles

Charles wrote > You were right. That address has gone. The Technical University is now at http://iv.tu-berlin.de/ but the rms/Almondbread file is not there ...

Hi Charles and Paul,

"Almondbread" - I had a look yesterday at different german websites sites, tu.berlin too, archives here etc. but at last without any good result too.
***
Chebychev, I like these formula too , some are on my site with different programs.

> http://www.Nahee.com/PNL/OrgForm.html (http://www.Nahee.com/PNL/OrgForm.html) :-))) - I had a try here ... gtc45 & UF ...

(http://i11.tinypic.com/4bfslg3.jpg)

Whatever we create with these wonderful formulas is individual but I think its a wonderful place at last to start from :-)))
I attach the file.

***
Comment here whenever its not the correct place :-)
Paul  - there was a lot of beautiful work incl. latest * XD Firework * I could see and admire here the last days - wonderful, all my compliments ! :)

Margit
***

Chebyfile here free for use/using ...
UF_gtc45 {
fractal:
  title="UF_gtc45" width=2730 height=2048 layers=1
  credits="MS;10/18/2006"
layer:
  caption="Layer 1" opacity=100
mapping:
  center=-0.62713878156195/-2.2121162415e-6 magn=1100.5748
  angle=75.9218
formula:
  maxiter=2500 filename="GFPTCH.frm" entry="gtc45" f_fn1=ident
  p_p1=4/2
inside:
  transfer=linear repeat=no
outside:
  density=0.25 transfer=exp filename="standard.ucl"
  entry="GaussianInteger" p_inttype="round(z)"
  p_colorby="angle \@ min" p_norm=none p_fac=2.0/1.0 f_normfunc=ident
  p_randomize=no p_randomsize=0.1/0 p_logseed=0.1
gradient:
  smooth=yes rotation=-100 index=1 color=0 index=11 color=14211288
  index=23 color=0 index=32 color=14211288 index=33 color=0 index=55
  color=14211288 index=69 color=0 index=82 color=14211288 index=93
  color=0 index=113 color=14211288 index=114 color=0 index=126
  color=14211288 index=143 color=0 index=152 color=14211288 index=170
  color=0 index=183 color=14211288 index=206 color=0 index=216
  color=14211288 index=234 color=1907997 index=247 color=14211288
  index=261 color=0 index=274 color=14211288 index=290 color=0
  index=302 color=14211288 index=316 color=0 index=316 color=16777215
  index=335 color=5000268 index=351 color=16777215 index=368 color=0
  index=-16 color=14211288
opacity:
  smooth=no
}

Hi!

Yes - the standard is high. I am working on a machine-code program to explore fractals.

This morning (Wed, 18 Oct 2006) I wrote a smooth palette - where the colours merge seamlessly into one another. I had obtained FRACTINT from the first address GFWorld gave, and made the Mandelbrot set. When I switched to the smooth palette, the coloured bands were still in place - the image did not become smooth.

The other address given by GFWorld has very smooth graphics. I am trying to decide how such smooth colours can be achieved without hand-editing the palette. Chaos theory says the dots are chosen almost chaotically, so the smooth palette breaks up. I had hoped this would not be so.

Many, many years ago I shifted C in order to "change the tilt of the complex plane". I based that assumption on the fact that X <- X*X + C gives the mirror image of X <- X*X - C. However, there is all kinds of "swirling" going on as one uses, say 0.9C or 0.8C etc. It is just a "coincidence" that the "swirls" turn upside down on negation of C. That is to say, you cannot alter the 3D perspective by changing the ARGUMENT of the function. It is "on the wrong side of chaos". You can only get 3D by altering the RESULT.

So as I plan to make 3D images, I realise that one only needs to make ONE calculation at each point. One has X, Y and the "bailout" count (height). So one shifts the X by a fraction of the baleout count on one image, and shifts the X the other way on the other image. That, I now know, is the way to get BINOCULAR 3D fractals.

Now I'm going back to my assembler.

Charles

Margit Schttler wrote:
>
>    Hi Charles and Paul,
>    Chebychev, I like these formula too, some are on my site with
>    different programs. http://www.Nahee.com/PNL/OrgForm.html (http://www.Nahee.com/PNL/OrgForm.html)
>    - I had a try here ... gtc45 & UF ...    Whatever we create with
>    these wonderful formulas is individual but I think its a wonderful
>    place at last to start from   :-)))

Hey there, Margit, I agree with you, the Chebychev type formulas are a good starting point for some unique and interesting images.

>
>    Comment here whenever its not the correct place :-)
>    Paul  - there was a lot of beautiful work incl. latest * XD Firework *
>    I could see and admire here the last days - wonderful, all
>    my compliments ! :)

Though I have several fractal related applications I use regularly, the reason XenoDream has been more prominent these days is because of the 3-D aspect.  Being able to rotate an object fairly quickly, render it, and then export it to be used as a 3-D object in other 3-D applications is the key factor.

Thank you for all your compliments!!  And looking forward to your next images shared in this Forum.

The story continues.

I was disturbed by the lateral symmetry of the strange fractal image. It seems that the bug is creating Z <- Z*Z + C where Z is ABS(X) + iY. It seems to be losing the signum (the sign) of X.

I played around with the program, hoping to discover the cause of the problem by gathering experience of its behaviour. Then I decided to subtract C instead of adding it. The program is http://wehner.org/tools/fractals/first/bizarre.asm which gives http://wehner.org/tools/fractals/first/bizarre.gif, shown here smaller:


I enlarged this sixteenfold  http://wehner.org/tools/fractals/first/bizarre2.asm to get  http://wehner.org/tools/fractals/first/bizarre3.gif and also (reduced in size) bizarre4.

 
Sixteenfold more enlargement gives bizarre5 and bizarre6:

 
Sixteenfold more again gives bizarre7 and bizarre8:

 
I am still looking for the bug.

Charles

Thanks for showing your images. It are all Julia sets of z=z^2 + c and z=z^2 - c

I think it could be interesting for you to see all Julia sets in mutual coherence.

See: http://www.fractalforums.com/index.php?topic=14.0

Here You see the Julius Ruis set. I developed the Fractal Imaginator (Fi) for further research of the Julius set.

Jules Ruis.

Jules Ruis wrote:
>
>    I developed the Fractal Imaginator (Fi) for further
>    research of the Julius set.

So, are you saying that you had full access to the Visual C++ source code that Terry wrote, so that you could do the development coding for that one small little aspect of this program ??

And this was why the program was written, to only do "further research of the Julius set", and nothing else ??

When did you write and compile this code to produce this program ??

I have been this way before, when I wrote "Almondbread.bas" for Qbasic. These are not the Julia sets, because they are all bounded. Julias are unbounded.

I thought I might find the bug by the method of Quasimodo walking backwards - I would just follow a HUNCH. The hunch was that in my code, the real (X) was somehow remaining positive.

I put some test code into my programs, like this:

Pushf
..............
.............
popf
jnc  moredots
push cx              ; Save the palette number
mov dl,7             ; The "bell" character
mov ah,2            ; The "print char" instruction
int 32                 ; Make it ring.
pop cx

moredots:
jmp chaosloop

This was put in several places in the code. After much tintinabulation,I felt like the Hunchback of Notre Dame, screaming "The bells, the bells....."

Both the real and the imaginary became both positive and negative at times. So the problem is not one of ABS(X) as I thought.

I then played around. I took unity away from the unreal, and got the following:


Here, I have changed the first two colours in order to show the circle of diameter 2 and the result of the first looping.

It looks familiar, looks very like some Julia images - but is the result of a bug.

There are two other copies of this at http://wehner.org/tools/fractals/first/curious.gif and http://wehner.org/tools/fractals/first/curious2.gif. The source is at http://wehner.org/tools/fractals/first/curious.asm.

I am still debugging. It is annoying, because I have plans for when the problem is overcome.

Charles

To Paul N. Lee,

Please let us try to help Charles with his programming troubles instead of discussing worthless questions.

Jues Ruis.

Do you know there are two kinds of Julia sets: with orbits and without orbits. Is this the same like you call bounded and unbounded?

I show two examples with the same coordinates.

1. Without orbits: www.fractal.org/Beelden/Julia-unbounded.jpg

2. With orbits: www.fractal.org/Beelden/Julia-bounded.jpg

Jules can you link to images please and host them on fractal.org or tinypic.com.

Ok. I changed.

Jules.

herr wehner,

i think you would benefit incredibly much from switching to c/c++ or java; fixed point arithmetic is no longer faster than floating point (to say nothing of accuracy and simplicity benefits), and assembler is no longer faster than c++ (perhaps java, but i don't imagine the disparity to be huge). i'd be happy to help you get started with either of these languages after my exams are over (thursday).

i programmed a little mandelbrot/julia iterator just earlier to procrastinate instead of studying calculus, took about 30 minutes including the image-to-palette code. the iteration code is literally "z_j = z_j * z_j + z_m" and the palette generation code is incredibly terse and efficient through use of the standard template library. it's speedy too, and produces reasonably high quality output (extreme example here: http://www.fractographer.com/propaganda/tlset.png) - with this kind of quick-programming capability i'm sure you could push your (very interesting) researches much further! i also had a good long read around your website btw ;)

anyhow, email me if you're interested and i'll send some instructions (what to download / how to set up) and sample code your way. i recommend java for its ease of use, but being used to assembler i'm sure you won't have much trouble with c/c++.

Lycium wrote: "i'd be happy to help you get started with either of these languages after my exams are over (thursday)". However, I have written in C, C++, Java, Perl, various Basics, Forth - I created my own, Occam and many other languages.

Real programmers shave their teeth and write in object. I am no longer young - my teeth are getting bald - so I switched to Assembler.

Debugging:
I wrote a test program around the maths section of the fractal generator. It uses 1/3 + i1/5, then -1/3 + i1/5, then 1/3 - i1/5 and finally -1/3 - i1/5. This is at http://wehner.org/tools/fractals/first/numbers.asm. The results are:

C:numbers
*************************
*         WEHNER`s                *
* OWLBROT FRACTAL MAKER *
* MULTIPLICATION TESTING  *
*        COPYRIGHT  2006       *
*************************
00.12345677

00.07111108 00.13333326
00.07111108 FF.86666667
00.07111108 FF.86666667
00.07111108 00.13333320

DONE
C:>

The first byte is in hexadecimal, the fractional part in decimal. The results are perfect.

Then I used 1.333333 + i1.2 etc. (numbers2.asm). Then 2.333333 + i2.2 etc. (numbers3.asm). Then 2.2 + i2.333333 etc. (numbers4.asm). Everything is as it should be, as shown at http://wehner.org/tools/fractals/first/numbers.txt , so it is NOT the mathematics that is wrong.

The search continues.

Machine code is like this. However, the programs are tiny and fast. Floating-point always involves bit-shifting. C always involves a core that somebody else wrote. I keep things simple and totally under my own control - even if I sometimes have a bug to sort out.

Charles

computers are sufficiently fast these days that you don't really need to worry too much about low level details, only algorithmic efficiency; the fact that we both do is besides the point ;) i was only suggesting it so that you could accelerate your experiments, since you seem to be struggling with things that shouldn't be a struggle in 2006 (almost 2007, and to be fair since 1995). also, i'd be interested to know how a fixed point exponent or sine/cosine would work without losing precision and months of coding time better spent ;)

and about raw speed: if i were to lay down a gauntlet, would you participate in the challenge to make something faster? :) accuracy also comes into play with the large images required for a good benchmark...

well, i can tell you're happy with asm and i don't want to suggest anything you'd be uncomfortable with, i was merely hoping the highly tangible benefits of speed (both of development and execution) and accuracy would appeal.

Thomas Ludwig ("lycium", fractographer) wrote:
>
>    .....assembler is no longer faster than c++ .....
>    ....i was only suggesting it so that you could accelerate
>    your experiments....
>    and about raw speed:  if i were to lay down a gauntlet,
>    would you participate in the challenge to make something
>    faster? :) accuracy also comes into play with the large
>    images required for a good benchmark...

Myself and several others have done benchmarks on coded programs written in Assembler, C++ and Basic, to compare the speed of each.  The result is that Assembler is still faster and can be written more efficiently.

If you want to try out a fractal program written in Assembler, there are two versions of "WManJul" available as FREEWARE from this location:   http://www.Nahee.com/Software/ (http://www.Nahee.com/Software/)

The source code is quite small and fairly efficient.

The problem has shown itself to be the algorithm, not the mathematics.

I had a similar problem when I programmed Almondbread.bas decades ago. There is some very subtle point about where to put in the constant. This problem arises whatever the language one uses. I started as a humble technical draughtsman, aged 18, in computers, in 1962. I became an engineer and designed computers from small-scale chips in the Seventies. And yes, I have owned and studied Kernhigan and Ritchie's book on C. It was the later edition after C++ arrived.

I modified the numbers programs into http://wehner.org/tools/fractals/first/series.asm , and series2 , and series3 . The results are exactly what one expects from a correct mathematical system.

The printout, at http://wehner.org/tools/fractals/first/series.txt , is crude. The integer is displayed as hex, and the fraction as decimal. However, checking the computations on a pocket calculator shows that they are all correct.

Perhaps it was a wrong idea to show in public how I develop a program, and how I debug. People think that it is like writing poetry, and every bug is an excuse for accusation or advice. That is not the way it is. All programs have bugs sometimes, no matter what one uses. I like to talk to the processor directly. To me, that keeps it simple. There are no unknowns, like the core programs of a bought-in item. It also means one can program from "ground zero". Given just an assembler, or a list of op codes, one is still not stuck.

Charles

i'm going to have to take that as a challenge :)

since i'll be doing optimisation contract work soon (game development) now that my exams are over, i might as well get some practice in. just a simple julia fractal computation, single and double precision, 32bit and 64bit, single threaded and multithreaded; if any one of them are beaten speed-wise with a result that looks good (will render a few zooms - i firmly believe integers are ill-suited to numerical problems exhibiting large scales), i'll be very impressed.

well, talk is cheap, i'm going to get cracking on that now i guess!

well, i've had my fun: http://www.fractographer.com/propaganda/fastjulia.zip

parameters: c = -0.74543 + 0.11301i, rendered on [-1.25,1.25]x[-1,1] at 1536x1024 with 12*12 supersamples per pixel, up to 128 iterations.

with 1 32bit thread it completes in 1:15m, with 2 64bit threads it's a bit less than half as long. i'd be interested to know what kind of times people get! it's still not completely optimised (in particular i'd like to add streaming non-temporal memory writes), but already i think one would be hard pressed to match this kind of performance and accuracy in straight assembly language without quite a significant time investment; the c++ code in its entirety is 190 lines, written in a little over two hours - if anyone wants to see it just shout.

last thing: i do hope this will be seen as my taking an opportunity to have some fun while showing that c++ isn't necessarily slower than even well-written asm - i too used to really enjoy my "down to the metal" programming before it all got too complicated, and having found that simple higher-level code in fact ends up faster (floating point code is also more accurate across large scales, which matters a lot for anti-aliasing), well, i just wanted to share that.

I do not accept challenges, nor give out challenges. Life is not war.

However, I have been there and done that. I have been in the world of floating-point, and way beyond 64 bit. I wrote mathematics to a precision of 65 places of DECIMALS. That was 28 BYTES (mantissa) and two bytes exponent.

A wicked government made problems for me - I lost most of my life's possessions. However, I rebuilt some of my earlier work.

The floating-point core is at http://www.wehner.org/fpoint.

When a language like C, or C++ is created, somebody first writes the inner core in assembler. When Inmos introduced the Transputer for supercomputers, they said that nobody ever programs in assembler any more. That is a joke. At an exhibition I met Sir Clive Sinclair, and repeated the joke. He said "That is what they want you to believe". Later, Inmos published the op-codes of the Transputer (which they had been keeping secret).

Here is another joke. Forth is written in Forth. I created my own version of "super-forth", with many added features. Forth is the only officially annotated list of subroutines. It can barely be called a language. However, it is the nuts-and-bolts of computer programs, and I think it is essential knowledge.

So Forth is "written in Forth"?  Suppose, on a RISC processor there is no subtract. We write : - neg + ;, where the colon starts the definition and the semicolon ends it. It simply negates the adder into a subtractor, the addend staying the same. Now we write : + neg - ;. This negates the subtractor and calls the subtraction. So the addition calls the subtraction, which calls the addition, which calls the subtraction until the return stack overflows and the machine crashes. Forth is not written in Forth. It violates Lord Russell's rule of set theory that a set of subroutines cannot be written in that set of subroutines - sets cannot contain themselves. A subset of Forth - the colon definitions - is written in Forth.

I was telling an expert that I had built a Forth with lots of machine-code, and was converting the subroutines ("words") one by one into colon definitions. "When the last one is converted", I said, "there will be no native machine-code left, and it will run on any processor". He said "That's nice", without any further comment.

Explain to me how a machine can run without a processor. If there is no machine code, one can removed the CPU and the system will still run - in one's dreams!

So there is always machine code somewhere - even if it is hidden from the programmer.

Charles

If you call DNA genetic code a series of subroutines clearly it can, or have I spectacularly misunderstood?  (again!)

i was very explicit in pointing out that i don't see this as any kind of war :/ that two programmers interested in low-level efficiency might compare performance ideals is natural, no?

frankly i'm very interested to see how fast your integer-asm iteration goes, and if i could egg you on to produce a strong result while having a bit of fun myself (i mentioned also that my forthcoming contract work also involves similar optimisation), where's the harm? i really must say i'm disappointed with this negative interpretation of what i thought might be a bit of fun. producing a 24576x16384 image (1.18gb) with 12*12 supersamples per pixel of up to 256 iterations in under 5 1/2 hours is fun for me, at least.


holy smokes... what kind of application needs such precision?! i know pi off by heart to sufficiently many decimals (far less than 65 i can assure) to describe a circle from the sun to pluto accurate to a metre, and that's widely considered sufficiently insane ;)


i read that, but must admit it's a bit secondary to my interests since i need accuracy across many scales. modern architectures also shun the horribly inefficient stack-based x87 architecture in favour of a direct-access scalar computation model offered by cpus starting with the pentium4 (which itself has been around for quite some time).

furthermore, i must admit i "cheated" and used 128bit simd instructions - they admit a remarkably efficient mapping to escape time fractal computation. on my amd k8 architecture box such 128bit operations have a latency of 2 cycles, and on the latest intels (so-called "core" architecture) they take only 1 cycle - a true 128bit machine! furthermore, there are now quad-core versions of that architecture, scaling to 3.4ghz. i'm going to look into getting a benchmark result from one of those machines soon; i would like to point out that this incredible performance scaling happens with exactly the same source code and binary, flexibility which i believe is not easily achieved without using an intermediate language (ignoring the fact that it took zero effort on my part - as it should be, since it's a very mechanical job to replicate jobs across cores and shouldn't be a human burden if possible).

the relevance of all of the above is that the straightforward c/c++ code would need just a recompile to make very good use of these new technologies. what's more, the way i wrote those 128bit operations is via so-called "intrinsics", which are essentially a bunch of macros and wrapper functions that map (often directly) to the intended cpu instructions. the difference is this: the operands are just variables, and the compiler handles the arduous and combinatorial task of instruction scheduling and register allocation. you're still coding the algorithm very close to the metal, but thanks to this elegant method of specifying it the compiler, which can try so very very many different combinations of code and measure which is fastest in the blink of an eye, is free to produce whatever is most efficient given the architectural resources available. i find it very difficult to believe that this isn't a huge step up from directly writing assembly in terms of resulting code speed, programmer effort and sanity, ease of debugging, future proofing, ...


everyone who's programmed in asm has encountered such ignorant attitudes towards their beloved "dark art". i'm 23, and already feel rather old telling younger programmers war stories about optimising inner loops for the pentium, trying to best take advantage of both the u and the famously-crippled v pipeline via careful scheduling. such an attitude is unfortunately, however, rather justified both in terms of business sense (development is costly, in most cases execution power is dirt cheap, so these days code is more for human consumption than machine consumption) and in terms of common sense: if cpus are so very capable of re-arranging in-flight instructions to perform well, coupled with incredibly good optimising compilers... well, it just makes sense to focus more on what really matters - getting the algorithm very clean and minimal, avoiding poor cache behavior. that's the #1 performance killer these days, since cpus run in gigaherz and memory in megaherz, and a cache miss costs hundreds of cycles (equivalent of a great many alu operations).

- i hope you don't mind if i don't comment on your forth war stories; while they are certainly appreciable i am far too ignorant of the language and its history to provide meaningful commentary in that regard -


this is the crux of my little discussion, and the main thrust of why i wrote the program i linked above: i am not suggesting that assembly is dead or useless, only that there are much easier ways to achieve much better results (given the metrics referenced previously) for the same time investment as would be spent on writing it in pure asm. that is the whole of it - there is no war - i saw that you were frustrated by things with which one should not be frustrated in 2006/2007, thought about how much you stand to gain by a slight change of gear (the way i code is still very close to the machine), and sought to try and show it to you. please don't read animosity into this :/

Heneganj wrote about a set of parts containing itself:

"If you call DNA genetic code a series of subroutines clearly it can, or have I spectacularly misunderstood?  (again!)"

You have hit the nail right on the head. Biologists are not mathematicians, so they got it wrong - and teach others wrong.

Here is the truth.

Something is always missing from the set of parts that came from the parents. This "missingness" causes childhood. From the environment, in subtle ways, the child proceeds to update itself. That is adolescence. When adult, the new being can reproduce.

So no child is a perfect clone of an adult. Not even a virus is a perfect clone of its parent.

This is the motor that drives evolution. It puts variety into the world.

Charles

I am still looking for the logical error in my program. It is not a bug. I have also been searching for my old Almondbread Qbasic program - to check the algorithm. No luck yet.

However, I changed the constant in the above program from -1 to minus one-and-a-quarter. Here is the result:


The full image is at http://wehner.org/tools/fractals/first/neg5by4.gif

There seems to be some fire inside it. I magnified it 256 times linear (65536 times area):


Larger image at http://wehner.org/tools/fractals/first/ravine.gif

A change of palette makes it look very fractal-like:


Larger image at http://wehner.org/tools/fractals/first/ravine4.gif

It is just sunset in the ravine where the turnips grow.

Charles

Please Charles, repeat your question.
Which mathematical formula do you use. Is this a Julia set of z=z^2 +c ( with c= -1.5 or about)

Jules.

Fractal programs. :) Also you may want to ask about the number of digits calculated in GIMPS.

I remember that when I wrote "Almondbread", I had received mis/dis-information, and had to correct that. Indeed, wherever I looked on the Web, I came across Z <- Z*Z + C. As I studied this, by the method of al-Khwarismi (looking at all the "parts" of the numbers), it became clear that this is a symmetrical formula - and must be WRONG for Mandelbrot.

I considered that perhaps it was really Z <- Z* (Z+C). That expands to Z⁴+2CZ³+C²Z²+CZ+C²Z. Well, I tried it:


Other images are at http://wehner.org/tools/fractals/grass/grass.gif and http://wehner.org/tools/fractals/grass/grass3.gif .
The source code is at http://wehner.org/tools/fractals/grass/grass.asm .

You can go to http://wehner.org/tools/fractals/NASM.EXE to download the assembler. It comes from http://www.gnu.org .
The package available from Gnu has the disassembler, and many useful files. To assemble grass.asm, put it together with nasm.exe in a directory.

From the DOS prompt, type nasm grass.asm followed by rename grass grass.com followed by grass. It will make a file called Owl.bmp which you can edit with picture-manipulating software like Photoshop, Photosuite, Paintshop-Pro or IrfanView and then save as a GIF.

I realised that this was not the answer, and moved on to try Z_{new Julia} <- Z_{old Julia}² + Z_Mandelbrot . Here the Julia co-ordinates are the working co-ordinates whilst the Mandelbrot ones are the starting conditions.

What I got was this:


The file that makes it is http://wehner.org/tools/fractals/man/man.asm

Another image is at http://wehner.org/tools/fractals/man/man.gif

Enlarged, it becomes this:


The larger image is http://wehner.org/tools/fractals/man/man2.gif

The source is at http://wehner.org/tools/fractals/man/man2.asm

At last I have the tools for my research.

Charles

fractal apps don't need anywhere near that kind of precision, since the number of pixels on the screen is limited to at most 5 orders of magnitude; what's more, since floating point numbers have the same accuracy across many scales, even with that resolution you can supersample to your heart's content - even with normal 32bit ieee754 i can readily produce really good looking 24k x 16k images with tons of supersampling. even if fractal computations were carried out with "infinite precision", no one would be able to tell the difference between that and normal 32bit float render.

about gimps: that's totally different, and inherently integer-based; ie, you don't need to represent stuff like 1/3, only ever-expanding integers. when multiplying huge numbers they actually use the fast fourier transform to achieve logarithmic time complexity, and afaik such computation doesn't extend to computing square roots, exponents, and stuff like that. the problem is definitely constrained compared to fully generic real arithmetic.

Yes, I have indeed got the algorithm sorted out. Here is the rosette from the image I showed earlier, but much enlarged:


It is available larger at http://wehner.org/tools/fractals/man/man8.gif . The source code is at http://wehner.org/tools/fractals/man/man8.asm

These programs differ only in the parameters BEGINX, BEGINY, STEPX and STEPY. When carefully and methodically altered, these parameters can bring in images from any part of the Mandelbrot set. Readers are free to take my programs and use them to make their own images.

Here is another view, from below that rosette:


Working from an internet cafe, where the disk drive barely works, I was unable to upload man6.gif - the larger version.

The axes can be seen clearly here:


Another image to examine is http://wehner.org/tools/fractals/man/man5.gif

I have said "Hi", by re-establishing myself as a Fractalist. You have seen my method of working. I shall now proceed with the research, and hope to show you some of the more obscure corners of the art, as soon as I have something worth showing.

Charles

Charles wrote >I have said "Hi", by re-establishing myself as a Fractalist. You have seen my method of working. I shall now proceed with the research, and hope to show you some of the more obscure corners of the art, as soon as I have something worth showing ...

To be honest / fair / ehrlich in german - I dont understand anything, because there is no mathematical background at last  :)

What I feel, is a lot of enthusiasm and I am sure I will have a look here >hope to show you some of the more obscure corners of the art, as soon as I have something worth showing ... !  :)

Margit

Unfortunately, this is not the standard mathematical sense of the word "bounded". The two sets shown are IDENTICAL, but with different colour-schemes.

My own Spin-orbit duality conundrum shows the problem of bounded and unbounded systems. A child spins a top. Looking INWARD towards the top, we see that the child has more than enough energy to do so. Looking OUTWARD from the top, we see that the child has put himself into orbit, also the playroom, also the house, also the planet, also the solar system also..... also..... There are no bounds.

Concealed in the relativity problems of Einstein was the "unbounded conundrum", that mathematics breaks down in unbounded systems. He never solved the problem, and never got a Nobel prize for it. Relativity was a project under development. He got his prize for photoelectrics.

The fractal equivalent is when we scan a page (say, from left to right and downwards). Each pixel has its own reserved space - one pixel wide and one pixel deep. If you colour it in, it is possible that the mathematical properties of the algorithm will enable it to blend smoothly with the next pixel. So a smooth flow of mathematics leads to a smooth flow of colour. The happens in the de Moivre "spin drier", where a pixel is allowed to orbit and to be stretched or squashed away from/towards the origin. That defines Z <- Z*Z

You add the "tumble" to the spin drier, where the pixel tumbles parallel to its original position relative to the origin. That adds Z₀, giving Z <- Z*Z + Z₀ - which is the standard Julia/Mandelbrot algorithm. The Mandelbrot pattern looks like a bundle of wet clothes. The drops of coloured water coalesce into a continuum. However, as the "tumble-spin-drier" proceeds, droplets of coloured water are thrown outwards into unbounded space.

If a droplet of water lands twice as far out as its starting place, there is an area two units wide and two units deep to fill. It cannot do this, so it has free space around it.

I have called it water droplets, but Fractalists prefer the term DUST, because it has no surface tension and is therefore infinitely divisible.

Charles

Charles,

Do you call this Julia fractal an unbounded Julia?

www.fractal.org/Beelden/Julia-unbounded-2.jpg

Jules.

(http://www.fractal.org/Beelden/Julia-unbounded-2.jpg)

This I cannot say, without knowing how it was made. It is because of what I call "congestion". Pixels have their own allocated space in a bounded system. They have no specific bounds in an unbounded one.

There is no spacial pattern in a Mandelbrot image - it is all colour pattern derived from the number of iterations. Julia plots have both spacial and colour pattern. Because the dots are scattered about, seemingly haphazardly, it can happen that several dots (of "dust") land in the same area, and seem to coalesce. This I call "congestion". However, when such clumps are expanded in a Julia set, they always reveal dust within dust.

Charles

I think I owe Jules Ruis an apology. I was going by Internet disinformation. Julia sets are not unbounded.

I have sorted it out. Each pixel has its range from the origin and azimuth angle:

With Mandelbrot, THIS is the vector of what we will call the "TUMBLE". According to de Moivre, one doubles the azimuth angle when one squares the complex co-ordinates:


According to de Moivre, one squares the range:


These two operations, the doubling of the angle and the squaring of the range, I shall call the "SPIN".:


Such a "spin drier" does not deliver fractals. The secret is in the tumble, which turns it into a mathematical spin-and-tumble drier. With Mandelbrot, the tumble is of a magnitude and direction parallel with the original pixel position relative to the origin:


This "spin-and-tumble" completes one iteration. The iterations continue for that dot, until the position escapes the 2-unit-radius circle. However, throughout the evaluation of that pixel, the tumble-vector is taken from that pixel:


So the tumble-vector changes from pixel to pixel in the Mandelbrot set. There are, however, infinite numbers of Julia sets - each with its own vector - which have a fixed vector, the same for all pixels. Here is one such Julia set. I have used minus root a half for the real (X= -0.707106781) and plus root one eighth for the imaginary (Y= 0.35355339). This works out as ninety pixels "tumble" to the left and forty-five upwards:


Both systems are BOUNDED. The pixel is scanned sequentially from an array. Each pixel has its own reserved space. There is no contention for space, no vector-graphics (spacial patterns). There is simply an analysis of how many recursions are possible, and then a colouring-in of the pixel within its bounds.

Charles

If the vector is fixed in a Julia set, and focused from the origin to the pixel in the Mandelbrot set, it follows that a Julia set that has the same vector as a Mandelbrot set should give the same image.

I explored the idea, by replacing

add  eax,[mandelx+offset]
mov  [juliax+offset],eax 

by

add  eax,beginx
mov  [juliax+offset],eax 

and the same for Y. This changed http://wehner.org/tools/fractals/man/man8.asm into
http://wehner.org/tools/fractals/julia/jman8.asm, giving the image http://wehner.org/tools/fractals/julia/jman8.gif :


Indeed, even though this is a Julia plot, it is clearly related to part of the Mandelbrot set.

I now doubled the steps from 128 to 256. The image would be 512 times enlarged instead of 1024 times (in each direction). This gave http://wehner.org/tools/fractals/julia/jman8b.asm , whose image http://wehner.org/tools/fractals/julia/jman8b.gif is


The "rosette", or "spider's web" is now showing on the left.

Then, I returned to the previous file, and simply arranged that the vector would be to the centre of the picture (midx and midy) in http://wehner.org/tools/fractals/julia/jman8c.asm which gave http://wehner.org/tools/fractals/julia/jman8c.gif



This is very much like http://wehner.org/tools/fractals/man/man8.gif


which is a genuine Mandelbrot image, equivalent to the Julia image above.

The similarity is due to the vectors being almost identical. The original Mandelbrot vectors are radiating from the origin:


It can be seen that the area (half a pixel wide by a half high) is quite far from the origin. When enlarged, it gives vectors as shown:


With Julia, these are parallel. With Mandelbrot, at this level of enlargement, they are parallel to less than a pixel but in reality they taper towards the origin. The subtle difference between them does explain why the Mandelbrot image has more yellow than the Julia image equivalent. The slight differences in the mathematics alter the number of recursions that are possible, and so cause subtle colour changes.

Charles