Last year, I made a program in TI BASIC to graph the Mandelbrot set.  There was already one out there, but I wanted to make my own as a kind of educational challenge to myself.  (Woah, that sounds so nerdy, but you guys can probably relate)

Well, it worked.  But it takes 30 minutes to graph.  I'm not ready to learn assembly at this point, so until Axe came out I resigned myself to half-hour waits.  But now, my new project is to make a fast, axe Mandelbrot set grapher.  The plan is the have it display the time a BASIC program would take, and then the (hopefully significantly shorter) time the axe program will take.  It would be a great way of showing the difference between the speeds of Axe and BASIC.  If it is fast enough, I could even throw in a grayscale layer at a higher iteration for visual effect. 

The problem, is that the Mandelbrot set is tiny.  It only reaches from -2 to about .6 on the real axis, and -.8 to .8 on the imaginary axis.  Checking the points would require numbers with decimals, and a method of multiplying them together.

To check a complex number c to see if it lies in the Mandelbrot set, you follow this pattern.
c , c^2 + c , (c^2 + c)^2 +c , [(c^2 + c)^2 +c]^2 + c ... and so on.  If c is unbounded, it is not in the Mandelbrot set.  The easiest way to check this is to see if c's real and imaginary parts are less than a very large number.  Now the program requires support for very small numbers and very large numbers!

Is devising a system for handling decimals even possible?  TI did it, but does anyone know how?  (their method may not be plausible for an assembly program anyway)  If only axe's variables could store decimals... *sigh*

very large numbers? if you have a complex number c = a + bi, as soon as sqrt(a^2 + b^2) > 2, you know its unbounded. it's a very nice property about the mandelbrot set that makes computing a lot faster. if the magnitude of the complex number has not exceeded 2 after your max_iters, then you assume it's a part of the set.

Edit: as for decimals, the author of Axe would just have to add support to tap into TI-OS's built in FP b_calls and store 9-byte vars

Floating points are just as slow as BASIC basically.  I did indeed make a Mandelbrot set program in assembly using the OS's floating point bcalls and it still took about 10 minutes to graph.  The only way I was able to graph the set with Axe Parser in under a minute was to use fixed point math instead of floating point math.  8.8 is really really fast and fits into a normal Axe Variable, however the resolution is low, you can't make the pixels any closer than .0039 apart (which is 1/256th) or else the image breaks down and pixelates.  You can increase the accuracy to 8.16 or 16.16 which are a little bit slower, but it would allow the pixels to have spacings as small as .000015.  If you're really daring, you can have an arbitrarily long fixed point number which is referenced by a pointer.  I'm going to be adding a new command soon that makes multiplication easier to do as soon as I can figure out an efficient way to do it.

While I was drawing out my ideas, much to my surprise I found that squaring a complex number (integers only ) is relatively easy to do with a four-column array. 

@Quigibo
Is this 10 minute grapher available for download anywhere?

I never released it becasue it was slow x_x  I still have the source code, but I tried it and it doesn't seem to be working.

Floating point numbers would be very difficult, but also possible.  You would just need routines for the operations you want, that would take pointers as arguments, and have it do the math on the pointers.

For storage, I presume that you could set the first byte to be the power of ten, and store the rest as BCD. (Binary-Coded-Decimal).  The math would probably be the hard part.  Any ideas for libraries, Quigibo?  Possibly using the OpenLib( and ExecLib commands.  (ti-84 only, I think, so those wouldn't work.)

For a fractal program where the values are never going to be displayed onscreen, I think a binary floating-point method would be more efficient than decimal.

what would be the binary floating-point method? Would it use base 10 or 16?

think of binary fractional numbers this way:
0.10000000b = half
0.01000000b = fourth
0.11000000b = three fourths
0.00100000b = eight
etc.
then you can translate it into hex, taking them in 8-bit chunks:
00.01h = 1/256
00.10h = 16/256 = 1/16
00.FFh = 255/256
C9.A9EB07h = 201 + 169/256 + 235/65536 + 7/16777216 = 201.663742482662200927734375

Edit:
it's interesting how numbers like one third are:
0.333333333... in base 10
0.555555555... in base 16

Edit2: fixed something misleading