Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: ACagliano on March 28, 2014, 05:10:17 pm
-
So here's a poll. My project is an update to my Polynomial program which aims to provide:
1. Chained parsing of polynomials. The program, this means, can evaluate something like (3x/(7x-1)) + (2x/(5x+3)).
2. Automated selection of functions based on things in the expression. For example the presence of an = would lead to solving.
Here's my dilemma. I know that TI-Basic is better for floating point math. Assembly is not, so I'm not even asking about that. Axe, however, provides routines for floats. When it comes to floating point math, TI-Basic is my friend.
However, the amount of scrap that would be needed to evaluate complex polynomials is, in my opinion, beyond what TI Basic can facilitate. I would need to use vast amounts of RAM, be able to retain the position of them and what they relate to, and so forth and TI-Basic would make that very hard. So for this, Axe is better I think. So, I'm kind of torn. Either way, i'm going to have an issue with something. I guess the question is, which struggle is the least of the evils?
-
Since you're using inputs and doing math I think you're going to want to code this in basic rather than axe. Not that its impossible in axe, its just more work.
-
Since you're using inputs and doing math I think you're going to want to code this in basic rather than axe. Not that its impossible in axe, its just more work.
Fair enough, but I'm at a loss as to how to create a chain-able math system. That's why i was thinking the memory flexibility of Axe/Asm.
-
Perhaps you could use opcodes in the basic program so that you can use both basic and asm?.
-
Perhaps you could use opcodes in the basic program so that you can use both basic and asm?.
A bit too involved, unless you're referring to using like the DCS libraries or something.
-
Axe doesn't have floating point but there is an Axiom for that. Also in asm you can use TI's floating point routines. ;)
-
What about Axe's: float{PTR} and EXP->float{PTR} ?
-
They convert a 16 bit integer back and forth.
-
Ok where is a link to the floating point axiom? I'll check that out.
-
Here you go : http://www.omnimaga.org/the-axe-parser-project/(axiom)-floating-point-math-(and-other-stuff)/ (http://www.omnimaga.org/the-axe-parser-project/(axiom)-floating-point-math-(and-other-stuff)/)
It dates all the way back from 2011 though so hope it works with Axe 1.2.2a. In the worst case scenario you'll only need to change some bits here and there. ;)
-
Axe doesn't have floating point but there is an Axiom for that. Also in asm you can use TI's floating point routines. ;)
Don't even think about starting to mention TI's FP routines... They're ridiculously slow.
-
But they exist and work. That's what you use on the home screen. ;) This axiom uses them by the way.
-
Update: screenshot of the opening graphics (launched via DoorsCS7). Captured by WabbitEmu.
And apparently very glitchy. The weirdness you see in the screen didn't even show up on the emulator itself, or on my calc.
-
Check out Xeda's assembly floating point routines:
http://www.omnimaga.org/asm-language/%28z80%29-floating-point-routines/
-
Are they asm or Axe? Bc I'm working in Axe. I've been looking into the Axiom :p
-
They are ASM but you can make an Axiom out of them anyway. ;)
-
So, the following Axe code isn't working:
input->A
length(A)->L
A+L->E
...
A= START
E= END
...
0->Q->R
For(Z,A,E)
If {Z}='('
Q+1->Q
End
If {Z}=')'
R+1->R
End
End
If Q!=R
//display some error about improper nesting
Repeat getkey(9)
End
Goto InputPoly
End
I test this with the following entry:
(())) and it just quits (which is what it should do if the error is not being triggered)
-
bump. anyone?
Edit: I've enclosed the binary so you can see the results. After input, the input is echoed back, then the length of the string is displayed. Notice, in the echo, the () aren't there... I know the ( are tokenized. As are the operators. But then, how do I test for them? Shouldn't BYTE = 'CHAR' work for checking if a byte IS something?
Try (())) as an input.
-
bump
-
FYI you can use ALL the TI-Basic floating point operations for normal OS floats through assembly with bcalls. You cannot do the same with axe. Its floats are less precise.
If you wrote this in Asm with bcalls, the actual math would probably be slower, but the results would be higher precision and any non-float logic would be a little bit faster. (Not tons faster because axe is really good at optimization for what it is) If you're familiar enough with assembly, don't ignore it as a potential platform for this project.
Although, looks like you've already started. Oh well. :P
-
FYI you can use ALL the TI-Basic floating point operations for normal OS floats through assembly with bcalls. You cannot do the same with axe. Its floats are less precise.
If you wrote this in Asm with bcalls, the actual math would probably be slower, but the results would be higher precision and any non-float logic would be a little bit faster. (Not tons faster because axe is really good at optimization for what it is) If you're familiar enough with assembly, don't ignore it as a potential platform for this project.
Although, looks like you've already started. Oh well. :P
I'm not proficient enough with assembly to do something as float-heavy as this. However, I've been told that the Axe floating point axiom actually uses the TI-OS bcalls, since it hooks into the OS variables in a way.
That being said, I'm having an issue with why a tidbit of code is not acting right. I posted a binary, as well as source, a few comments up, as well as what it should do, and what its doing.
-
I can't help you at all with Axe, if you decide to incorporate some assembly parts i can (try to) help you out with that. Or if you want to talk about theory/algorithms. Inspired by your posts i actually started writing some simple parsers (in assembly), too.
-
Nice to know I've inspired someone :p lol. However, I'm now left in a pickle lol.