But that also means that I have to multiply my first integer by 256, right ?
It depends on what you mean. The routine I gave takes an 8-bit integer and returns an 8.8 fixed point number. To multiply that by something else, you would need to multiply the other number by 256 (which is 3 bytes, 11 cycles in Axe). So what I mean is, if you want to multiply A/21/12*B, where A and B are integers, you would do:
AAsm(<code>)**(B*256) In asm, this could be optimised a bit, maybe even in Axe (not sure). However, this part of your code probably doesn't need to be really fast.
You just divide by 256. In this case, if you do that, it would round down, though.
In Axe, if you do 3.5→A, it actually stores 896 to A (896/256=3.5). Then if you do A**A, you get 3136. 3136/256=12.25.
If you are doing 12root(X) times or divided by anything, then using Axe's fixed point will give you better accuracy in the end result. If you are only doing addition and subtraction, you won't gain accuracy.
And thanks, the first one (the one which finishes with 63) works The second one doesn't however, but I didn't find any precision problem for now in the test music I have with that Thanks
Remember that the second one is fixed-point, not an integer. I actually tested that code this time and it worked For example, 77→18606 = 72.6796875 instead of 73. The actual value is about 72.67832208.
And yup, the calculators are loud on actual hardware
I believe there is a language barrier issue going on here.
Keep in mind that while Omnimaga is primarily an English speaking forum, we have many members whose first language was not English. It is possible that most people here aren't native English speakers.
It is very easy to cause confusion when not talking about programming and it is easy to insult people unintentionally. Stefos' post that kind of started it all was a post of frustration and I think it wasn't intended to insult anybody. However, it was insulting.
I think that due to the expectations Stefos' had, they have grown up in a culture where only one language is spoken, or if any other languages are present, it is always translated from English not to English. This could cause the naive expectation that non-English languages have a natural translation to English that can be easily completed by a computer, or anything other than oneself.
Something that is normally funny, but may be insulting here, is the following quote:
Quote from: Hot_Dog's Signature
There are people who can speak two languages, and they are called bilingual. There are people who speak three languages and are therefore trilingual. Then there are people who speak one language, and these people are called Americans.
Well, you have to keep in mind that there aren't nearly as many programmers that have the 84+C as the older models. Also, the older models have been around for about 17 years, the newer model has been around for nearly a year.
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.
Spoiler For How To Do It:
/8 is actually really easy in Axe. Remember that 20/8=2. However, if you use fixed point division (use /*), 20/*8 will return 840. This might seem illogical, but you will notice that 840/256=2.5 = 20.0/8.0. Axe is not the only language that uses integers unless you tell it specifically not to. C, C++, Python, MatLab, Sage, Mathematica-- all expect integer operations unless you tell it specifically not to. Now, if you try to do 20/*7 on the other hand, you get 731, and 731/256 is not exactly 20.0/7.0. This is due to precision errors because we have only a finite amount of memory to work with and in this case, that precision ends at 8 bits. The calculator has 14 decimal digits of precision, many standard computer routines have 24 bits, 53 bits, or 64 bits of precision (approximately 7,16, and 19 decimal digits). The 24-bit one has been the standard for decades. The Z80 processor is an 8-bit processor, so it is much slower to work with anything larger than 8 or 16 bits.
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.
.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.
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.
This isn't a FileSyst update, but rather an allusion to what will hopefully come in the future.
Today I worked on putting together the basics of YAI (Yet Another Interpreter), but with more goals in mind, specifically working with variables. I am trying to put together a multiply command as a proof of concept, and it is not done. The parser currently does all of the following:
- It uses a GDB var for RAM storage (instead of an Appvar) - It parses the input string by checking if it is a number or letter to start. If it is a number, it converts the number either to an integer or to a float (the float conversion isn't working yet). If it is a letter, it searches the built in command list using a binary search, allowing alphanumeric values (uppercase, lowercase, and numbers). If no match is found, it searches user defined variables and functions. - Integers are arbitrary precision, up to 2040 bits. - The GDB variable holds a stack for intermediate calculation and for general purpose (similar to the OS floating point stack), followed by an index for the variables, which are stored alphabetically
Because memory management is going to be so dynamic, I made a custom InsertMem/DelMem routine to update all appropriate pointers and the size of the GDB var. I made a PushAnsStack and PopScratch routine which is used by the parser when parsing inputs an outputs to functions. These use the custom insertmem/delmem routine, of course.
I tried to make my current system easy for me to work with, I am trying to get the biggest hurdles out of the way first, but I still need to write the floating point conversion routines (string→float, float→string). After this, making the commands should be much easier.
As it currently is, I can get right in and start making integer routines. I also have code ready for lists, arrays, and string variable types. I have not yet added creating and storing to variables, but reading from them should work. I only just finished all of the memory management, so the rest will be for the next time I get a few days off from work
For an example, I have put together an integer multiplication routine. The interface isn't the best, but for testing, it works okay. It shows using the MUL() command for multiplying integers. I put the code in prgmTEST and then the app "Interpre" reads prgmTEST and executes whatever is inside. Once it is finished, it passes the last result into Ans as a string.
It is actually slower than most libraries (I am sure I can make a library slower, though ). However, it doesn't have any dependencies, and for anybody that can't send apps or programs to their calc, they can just open this BASIC program in Source Coder 3 or something and copy it onto their calc and be able to use customised assembly code for their games.
As well, it has no dependencies other than it needs to have the TI-OS or something compatible.
Just for clarification, are the large spans of unlabeled RAM such as at $843F or $89EC all untouchable? Or just unknown?
I believe 843Fh is where the OS interrupt handles key presses and such. If I remember correctly, 843Fh holds the current key press, 8445h holds the last registered key press, and the other in between are counters. Specifically, 8442h is used for repeating keys, starting with a value of 50, counting down to zero. If it reaches 0 and it is a repeating key (arrows or [del]) it repeats the key press, and resets the counter to 10. This is why the initial delay is longer after pressing arrows and such. I read these RAM areas because it is much faster than a silly bcall You do need interrupts enabled, though.
EDIT: Actually, rereading your post, ZippyDee, I think you read the values like "1087" and "1434" as the size of the gap. instead, if you subtract 8000h from the address and convert to decimal, you will see these are just the offset into RAM
The only value that is off is for the input 98, which is off by 1 after rounding (but only actually off by a rounded value of <1/3000). This routine can be easily modified to give the 8.8 fixed point result in case you need more accuracy. I forgot if you are building a table with this routine? If so, more accuracy during the calculations can help prevent larger rounding errors. Since my routine actually throws away 10 bits of extra accuracy (it has 18 bits of accuracy) you can do:
;263 t-states, 36 bytes Asm(AF555F444D290929444D2929290929092929172917098B29172917098BCB256C67EBED52) It is the same size and speed and the error is less than 1/256 from the actual for all inputs.
Also, I just looked at the previous hex codes I gave you. I did make typos >.> A bunch of "29"s where supposed to be 09. I also forgot one of the 29s. That's why my tests were working (I just compiled the assembly with ORG to do a quick test) but yours weren't. Sorry
EDIT: It is 281263 t-states for the 8.8 fixed point version. EDIT2: Optimised by using the formula X-(6X*613)/65536 instead of X-3678X/65536. The difference is that I split up the multiplication to multiply by 6, then 613. 1 byte smaller, 18 t-states faster.
Show Posts
