Charles says "Hi"

[Charleswehner]

Hello again.

I said I was writing some machine code to explore the more obscure aspects of fractals, like binocular 3D and Chebyshev functions.

Well, I wrote a program which is here : http://www.wehner.org/tools/fractals/first/demoivre.asm

This is supposed to follow de Moivre's theorem for Z <- Z*Z where Z is a point on the complex plane, having an angle to the X-axis and a range. You multiply range by range and double the angle. This should give circles - which are not fractals.

I got this:

The bigger (512 pixels square) image is at http://www.wehner.org/tools/fractals/first/demoivre.gif

The machine-code program was assembled with NASM, the "Net Assembler", available from GNU. I have also put a copy at http://www.wehner.org/tools/fractals/nasm.exe . Anybody who wants to create the machine-code file demoivre.com can fetch it and the source code. One types "nasm demoivre.asm" and later "rename demoivre demoivre.com" to make the command.

The next thing was to put in the constant C, to create Z <- Z*Z + C , which is the Julia-Mandelbrot formula. C is usually 1.

I put it in, as can be seen at http://www.wehner.org/tools/fractals/first/strange.asm

Here is the result:

There is a bigger version at http://www.wehner.org/tools/fractals/first/strange.gif.

Unfortunately, this is not what should have happened. The Mandelbrot image should have appeared. I have spent the last four days staring at the page trying to debug it. These things happen routinely with machine code. Eventually, I will find the tiny bug and progress will return.

In the programs above, the detail is very soft, so I hand-edited the first few palette colours. If the "not cl" instruction is removed (just before Mandelbrot plotting), the palette colours will run backwards (black instead of white etc).

The constant C should be put in after the test for range. Just for fun, I put it in before. The result is this:

The bigger version is at http://www.wehner.org/tools/fractals/first/hearts.gif

I hope these things are of interest to fractalists.

Charles

[Charleswehner]

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

[Jules Ruis]

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.

[Nahee_Enterprises]

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 ??

[Charleswehner]

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

[Jules Ruis]

To Paul N. Lee,

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

Jues Ruis.

[Jules 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

[heneganj]

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

[Jules Ruis]

Ok. I changed.

Jules.

[lycium]

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++.

[Charleswehner]

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

[lycium]

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.

[Nahee_Enterprises]

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/

The source code is quite small and fairly efficient.

[Charleswehner]

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

[lycium]

[...] The result is that Assembler is still faster and can be written more efficiently.

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!