Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Michael.3545 on June 25, 2010, 06:19:02 pm
-
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*
-
It would be nice to see such program. I always wanted to see with more kind of programs how BASIC and Axe compares.
-
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
-
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.
Well, that takes care of the large numbers, but I am still at a loss of how to implement sub-integer numbers with the current version. Can anyone think of a way of doing this with expanded values?
-
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.
-
Cool, built in fixed point support will be nice!
-
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?
-
The 10-minute one? I'm not sure where that one is, but I can get you the link for the 1-minute one.
Edit: 1-minute Mandelbrot set is at http://ourl.ca/4129/97657 (http://ourl.ca/4129/97657) I'm not sure if the 10-minute one was ever released, you may have to ask Quigibo personally, if he even has it still.
-
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.)
-
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.
-
I think a binary floating-point method would be more efficient than decimal.
agreed. It's actually kind of silly that TI stores it's floats as decimal. It wastes a lot of memory having lots of bytes that will never use A-F. The only reason for it was to may the number displaying routines faster and easier to code. Who needs that?
-
what would be the binary floating-point method? Would it use base 10 or 16?
-
Base 2 I belive. It makes all the arithmetic a lot easier because instead of multiplying by 10, you would be multiplying by 2, which is a lot faster in axe :)
-
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
-
So numbers would go like
0.0
0.1
1.0
1.1
2.0
2.1
etc?
EDIT: Nvm just saw Quasi's post. It seems rather confusing to me. Something I would rather use as less as possible unless necessary
-
Yeah it's a head hurter for sure. I might try to write a binary floating number library really quick for fun. The main thing is that you wouldn't have to work in binary :P the program would.
And Dj, it's just like regular binary (only 1s and 0s) but you put a decimal point somewhere. When we write binary normaly, it's at the left, we just don't write it.
101. In binary = 5 in decimal
Buuut if we move the decimal point in the binary number to the left
10.1
we divide the value by 2, so it now has a value of 2.5 in decimal. It's a bit tricky, but it has rules to convert to and from
-
Yeah, well my issue was more about using it inside games. Imagine when it comes time to do complex maths and the like and you need to convert your numbers from decimal to binary or vice versa everytime. It will take so long (like when we had no sprite to hex tools, it took me about 5 minutes to make one 8x8 tile)
-
that's true. you would need to know how to convert if you writing a game, so that you can put it in the source code. There are two options: have someone write routines to convert all necessary numbers first thing during the game's initialization so that they can still be in decimal in the source code, or someone could whip up a quick command line program to do it for you when your writing the game
-
When Axioms come out, this could make a great one.
-
Actuy all numbers in Axe are stored in binary to begin with (shhh don't tell anybody). Which is why base 10 floating point is so difficult (coding wise). Binary floatig point is easier to code but harder to wrap your head around.
And I use omnicalcs base conversion feature to make all of my sprites XD
-
I never could get Omnicalc base conversion to work before D:. It always didn't convert at all. Keep in mind the last time I tried it was in 2002, though (Omnicalc 1.0 and 1.1).
-
The syntax is something like this
Baseconvert("Number",Base1,Base2)
i wonder if it was glitchy back then o.O I sometimes forget to put the number in quotes though
-
IIRC the syntax was different, but I'm not sure anymore. I think you had to do something like 20h (new tokens inserted by Omnicalc)
-
Hurm maybe thats how it used to be, but its not doing that for me anymore on version 1.26
-
well, if anyone still wants a command line program to convert decimal floating points to hex floating points, here you go. hand written by yours truly. max precision is 8 bytes after the decimal point. let me know if there's any bugs.
edit: it will crash if the input number is too long
it does not support negative numbers!:
it's up to the implementer of the floating point routines whether negatives should be one's complement of the positives, or should the msb just be flipped?
i.e.: since 32.25d = 20.40h, should -32.25d = A0.40h or DF.C0h ?
-
I'm dying for real decimal support in Axe... If someone would make an axiom, I'd be willing to take a speed hit.
-
well, if anyone still wants a command line program to convert decimal floating points to hex floating points, here you go. hand written by yours truly. max precision is 8 bytes after the decimal point. let me know if there's any bugs.
edit: it will crash if the input number is too long
it does not support negative numbers!:
it's up to the implementer of the floating point routines whether negatives should be one's complement of the positives, or should the msb just be flipped?
i.e.: since 32.25d = 20.40h, should -32.25d = A0.40h or DF.C0h ?
The program can't start because MSVCP100.dll is missing from your computer. Try reinstalling the program to fix this problem.
-
here it is
it probably has something to do with me being on 64-bit windows 7 and using visual studio 2010
if all else fails, you could build the source yourself
-
Probably more the later, because I do not have Visual Studio installed. I got 64 bit Windows 7 too.
Also where would I put that dll file? The last time I had a similar problem, I put the OCX/dll file in the system directories (tried a bunch of them) and it still gave me the error
-
hmmm, try putting it in the same directory as the program
-
Tried, doesn't work either. Oh well, I give up on this now, else it will only lead to frustration spending hours trying to figure out how to run programs in particular, like usual, and it builds up.