SamTebbs33, Axe doesn't use floats. It uses 16- and 8-bit integers, and has some 8.8 fixed point support.

Axe is a much lower level language then TI-BASIC, which means that it works closer to the processor level. You get to be more precise about what you want to happen allowing you to get much faster results than TI-BASIC. However, TI-BASIC has all of the coding for very complicated (and time consuming) mathematics.

Axe is a very different language from BASIC, so the BASIC tricks that you might want to use in Axe aren't very useful and likely inefficient.

What exactly are you trying to do? In Axe, there is probably a much better solution than one you might use in BASIC. It'll take some getting used to, but Axe is well worth learning

Also, welcome to Omnimaga! You should introduce yourself.

EDIT: Have you read the Readme that came with Axe? It describes these a little bit, as well as the idea of pointers and such-- you won't be able to use strings the way you would in BASIC, for example.

Also, to answer the question "will they be useable in the future" Runer112 has mentioned in the past that he wants to add a broader range of variable types to Axe, among them being floats. For now, you can use fixed point 8.8 numbers.

Integers are usually better if you can figure out a way to use them, but occasionally you actually need fixed-point for optimal coding. Internally, fixed-point numbers are stored times 256. So 1.5 is really 368. 256 is the first number that doesn't fit in an 8-bit (1 byte) range and dividing or multiplying by 256 is very easy (remember that in Axe, dividing by a number is like int(A/B) in BASIC).
Anyways, if you did 1.5*1.5, you can think of this mathematically as 368*368/(256*256) then multiplied again by 256 to convert it back to fixed point. At the assembly, you just multiply 368*368 and get rid of the lower byte of the result, keeping bits 8 to 23.

Integers are usually better if you can figure out a way to use them, but occasionally you actually need fixed-point for optimal coding. Internally, fixed-point numbers are stored times 256. So 1.5 is really 368. 256 is the first number that doesn't fit in an 8-bit (1 byte) range and dividing or multiplying by 256 is very easy (remember that in Axe, dividing by a number is like int(A/B) in BASIC).
Anyways, if you did 1.5*1.5, you can think of this mathematically as 368*368/(256*256) then multiplied again by 256 to convert it back to fixed point. At the assembly, you just multiply 368*368 and get rid of the lower byte of the result, keeping bits 8 to 23.

I've used Axe for a while and I never knew that... Thanks!

However, as soon as I saw demos of Axe (the spinning cube really got me) I decided to give it a shot.

Have you seen what Matrefeytontias is up to?
http://www.ticalc.org/archives/files/fileinfo/457/45784.html

Your BASIC solution to storing data isn't as good as you might think, unfortunately. Internally, a Real number is stored as 9 bytes, a complex number is stored as 18 bytes. All four of those numbers could be stored as 1 byte each in Axe, and you can store them as an array of data.

Now to get the integer and decimal part of 20/8, for example, note that there are no such things as fractional numbers to the processor. The processor only works with integers 0 to 255 (or 0 to 65535 in some cases). TI-BASIC works with this just by representing and working with these integers in specific ways to pretend it is using floats. In Axe, since I am assuming you don't have assembly experience or similar experience with low-level language, this would be very difficult to simulate.

To give you an idea, the OS stores the number "pi" as the sequence of 1-byte integers:
{0,128,49,65,89,38,83,88,152}

That probably makes no sense and it will probably just confuse you more to work out the details of it.

My point is, I think you want to think of things in terms of decimals, but they don't exist on the calculator unless you make them. You make them just by handling your data differently. For example, 20/8 is 2. 21/8 is 2. 22/8 is 2.

I know how to get the fractional part, but my worry is that you are going to cling to this and that will make it a lot harder for you to learn Axe. Also, the explanation would require lots of math.

---

What I think will be more beneficial is if you learn how pointers work. You also will benefit from knowing how memory reading/writing works. Remember, TI-BASIC uses 9 bytes for their floats. Axe uses 2 bytes for integers/pointers (all variables in Axe are pointers). You can also store arrays in Axe and reading/writing to and from arrays works with one byte a t a time. This means that if you can represent your data with integers 0 to 255, you can use a single byte instead of 9 or 18.

As some things you should try:
.TEST
"HELLO WORLD!→Str1
Text(0,0,Str1
Str1 does not contain a string. Str1 is a 16-bit integer that poitn to the spot in RAM that the string is located at. Try this:
.TEST
"HELLO WORLD!→Str1
Text(0,0,Str1+1
You should see "ELLO WORLD" displayed because Str1+1 points to the "E" in the string instead of the "H".

Also be sure to look at the command index. Read through it. Get some ideas of what you can do with certain commands, like the Data() command or []. You should have a copy of it with Axe, but there is also a convenient copy here.

Thanks for the explanation, I think I need to investigate the assembly number system a bit more. The only real knowledge of binary that I have is bitwise operations and the basics (so I was very excited when I saw that the " and " et.c commands are bitwise operations in Axe , I had to write my own in TI-Basic).

Regarding my choice of data compression, I originally used that method to 'bypass' the dimension max of lists in Ti-Basic, it meant that I could store multiple numbers in just one list element. But I do understand that it uses large amounts of memory due to the decimals and imaginary numbers.

I'll put aside my games programming and just go back to basics to ensure that I understand the system fully (such as the r command et.c)

One last question for the moment, how would I recall the data that I stored to the memory by using [<hex code>]? Would I use a GDB pointer?

And randInt(A,B) would be rand^(B-A)+A in Axe.

Thanks! I'll keep that in mind.

Here is a list of commands that Axe does recognize:
http://axe.eeems.ca/Commands.html#systemCommands