Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: Hot_Dog on April 28, 2011, 03:44:08 pm
-
In a further attempt to speed up text-based games, I'm working to add some code for Correlation to compute arguments inside of ln( and e^(. This will happen only if your arguments are simple, otherwise Ti-Basic will compute the arguments.
By default I'll allowing addition, subtraction, multiplication, variables, abs( substrings, parenthesis, Ans, L1-L6, Martices, strings and temporary strings. For instance, this would be totally valid:
Output(2M,17-Ans,L1(Ans
I know that these appear a lot in games. However, is there anything else that you guys use A LOT? Please vote, and give suggestions of your own if you think of them.
-
Division, definitely. sin( and cos( occasionally (for circular structures).
-
I forgot to mention, by the way, I'm not going to add int( because all parameters except strings will be turned into integers anyways.
-
What about iPart(? XP
Yeah, usually the only times I use sin( and cos( are for circular things. I like to use log(, often, but that is usually to find the number of digits in an integer. Maybe you could make log( do that instead? (meaning find the number of digits, minus 1)
-
I've actually never heard of times when people would need the number of digits for Output( and Text(. Can you enlighten me, please? :)
Just a reminder, you can still use ln( and e^( if you have really weird functions, they just won't be super-duper quick.
-
Centering text, right justifying text. If it's a number you need to know how far to place it out from the side.
-
Centering text, right justifying text. If it's a number you need to know how far to place it out from the side.
Yes, exactly :) I also use it when I am making math programs that output results in a more pretty way :)
-
Hmmm...Never thought of that. Okay, I'll put in log( for that.
-
Cool, that will be great! As an example, if I know a number is an integer and I want to right justify it so the last number is in the ninth column:
Output(1,iPart(10-log(Ans)),Ans
-
What about just sending the entire argument string to the OS to evaluate?
-
What about just sending the entire argument string to the OS to evaluate?
The OS does it by default, but it's too slow. I'm making this a faster one, since most people don't use Anova( or Sort( or other complex ones like that
-
You are trying to parse things yourself, for speed, right?
-
What about just sending the entire argument string to the OS to evaluate?
The OS does it by default, but it's too slow. I'm making this a faster one, since most people don't use Anova( or Sort( or other complex ones like that
Anova(? I don't even have that o.O
-
You are trying to parse things yourself, for speed, right?
Exactly. The problem is order of operations will be left-to-right (excluding parenthesis), so converting old games will be slightly tricker now.
Btw, slightly off topic, but thanks Runer112 for reminding me of using the stack to help out with this
-
For infix parsing, convert to postfix first. It makes your life SO much easier. But left-to-right parsing would be even easier than that, I suppose...
-
Btw, slightly off topic, but thanks Runer112 for reminding me of using the stack to help out with this
Oh I bet that is how Axe does it... I use a completely different method which is why ReCode does math right to left...
-
What's infix and what's postfix?
-
Btw, slightly off topic, but thanks Runer112 for reminding me of using the stack to help out with this
Oh I bet that is how Axe does it... I use a completely different method which is why ReCode does math right to left...
I think Axe only does that for parentheses (and implied parentheses).
What's infix and what's postfix?
Infix is your familiar 1*2+3 notation (disregarding order of operations); postfix is basically RPN (reverse polish notation), described here: http://en.wikipedia.org/wiki/Reverse_Polish_notation
-
Yeah, I think I'll stick with left-to-right. Postfix is a little bit tricky for someone at my level ;)
-
prefix (a.k.a Polish Notation): + 1 2
infix: 1 + 2
postfix (a.k.a Reverse Polish Notation): 1 2 +
with infix you have to worry about order of operations, whereas with postfix and prefix you don't.
While we're on the subject...
http://xkcd.com/645/
-
While we're on the subject...
http://xkcd.com/645/
:P
-
prefix (a.k.a Polish Notation): + 1 2
infix: 1 + 2
postfix (a.k.a Reverse Polish Notation): 1 2 +
with infix you have to worry about order of operations, whereas with postfix and prefix you don't.
While we're on the subject...
http://xkcd.com/645/
Lovely :P
And now I know what those terms mean, so I am happy... I think it would be slower to use those methods, anyway, in my experience.
-
Well, the slow part would be converting from infix to prefix/postfix. Parsing prefix/postfix is actually much easier to write as long as you have sufficient access to a stack/queue
-
Wow, ZippyDee, you wouldn't by any chance be willing to contribute to Correlation by writing this parser, would you?
-
Well, the only issue is that my ASM is a bit on the completely awful side. But I could give it a go. At the very least I could write a low-level pseudocode for implementation.
-
So, would we code in order of operations, left to right, right to left, or RPN?
-
I think the easiest for general users (albeit the slowest) would be to parse from infix to postfix, and then parse the postfix.
That would allow them to still use regular order of operations and not get all confused about left-to-right order of operations or right to left or RPN or anything else like that.
-
Well, the only issue is that my ASM is a bit on the completely awful side. But I could give it a go. At the very least I could write a low-level pseudocode for implementation.
You know what, if you could write some pseudocode -- any level, it doesn't have to be low-level -- that would actually help tremendously. I could actually take it from there. The main headache for me is the planning part, and then the coding is not so hard from there.
So, would we code in order of operations, left to right, right to left, or RPN?
Left to right. Again, if you absolutely need order of operations, the Ti-Basic parser can do it instead of my parser.
EDIT: I agree that regular order-of-operations is easier, but then Axe parser uses left-to-right, so it's not like it's impossible
-
I forgot...to make math faster and more efficient, Correlation converts all numbers to 16-bit binary, instead of BCD. So for log(, you will only be able to supply variables (like real numbers or list elements) with absolutely no math. Log( will then safely calculate the number of digits in your number.
-
A base 10 logarithm routine should be a piece of cake. This takes 57 cycles in the best case scenario (result=4) and 143 cycles in the worst case scenario (result=1). It's 32 bytes.
Log10:
ld de,4
ld bc,-10000
add hl,bc
jr c,Log10End
dec e
ld bc,-1000-(-10000)
add hl,bc
jr c,Log10End
dec e
ld bc,-100-(-1000)
add hl,bc
jr c,Log10End
dec e
ld a,l
add -10-(-100)
jr c,Log10End
dec e
Log10End:
ex de,hl
ret
-
Shouldn't that be able to go down to 0? numbers 9 and below?
-
I personally voted division and square, if it's not too late.