1126
Axe / Re: Code optimization
« on: June 18, 2010, 11:08:08 pm »
there's a reason there are too many parantheses. that's because there are approximately 136 of them. at once. calling subroutines. trust me, i saw this comming.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to. 1126
Axe / Re: Code optimization« on: June 18, 2010, 11:08:08 pm »
there's a reason there are too many parantheses. that's because there are approximately 136 of them. at once. calling subroutines. trust me, i saw this comming.
1127
Axe / Re: Code optimization« on: June 18, 2010, 10:32:33 pm »
i got a stack error when compiling it oh well.
source is attached in case anyone wants to figure out what it would do (: note: i suggest you use sourcecoder or something of the like to view it.. since if you're viewing it on-calc you're going to have to scroll through about 40 lines of just sub()'s, and then 8 lines of just closing paranthesis. then you get to the alll the wonderful labels that make it possible. 1128
Axe / Re: Code optimization« on: June 18, 2010, 09:11:27 pm »
if axe supported floating point, i would make this the most epic quadratic solver known to man. because i'm lacking in that department, this will be.. interesting.
1129
Axe / Re: Code optimization« on: June 18, 2010, 08:59:10 pm »
psh, whether or not you were kidding i am going to try a program with that.
edit: i'm twelve and what is this? 1130
Axe / Re: Code optimization« on: June 18, 2010, 08:51:52 pm »
excuse my french but... mindfuck? i dare someone to have a program with 20 subroutines and the line that DJ just posted only. and it has to do something useful.
1131
Axe / Re: Code optimization« on: June 18, 2010, 02:52:22 pm »Code: [Select] If X<95 and getKey(3):X+1->X:sub(A):End can be (in axe 3.0) Code: [Select] If X<95 and getKey(3)
1132
The Axe Parser Project / Re: Axe Tokens (Read Post Before Voting)« on: June 17, 2010, 08:19:57 pm »
eh, i don't think it's so bad. regardless, anyone who's bothering to switch from BASIC syntax to Axe syntax definitely has enough determination to figure out how different token names work. all you need is about 2 sentences of documentation to explain the feature, how to toggle them and that there is no difference between Conj( and Copy(
1133
The Axe Parser Project / Re: Axe Tokens (Read Post Before Voting)« on: June 17, 2010, 08:14:38 pm »
int() (changed to sign{ )
i n t ( ) (not changed to sign{ ) people would figure it out rather quickly. 1134
The Axe Parser Project / Re: Axe Without Token Hook« on: June 17, 2010, 06:34:32 pm »
i like galandros' solution, but it would be hard to upkeep since axe is constantly changing. that may be a better solution once axe nears completion though. i think flexibility is key here, as new token names are definitely beneficial, the old ones may confuse new people programming in axe. therefore i like my idea of having a look up table in case a new person stumbles upon some old code, or galandros' solution so that at least the new people know that they're looking at old code, and thus need to convert it. regardless, since you can switch between the token names on-calc, even a non-programmer could figure out how to convert two pieces of code given adequate instruction.
1135
The Axe Parser Project / Re: Axe Without Token Hook« on: June 17, 2010, 06:07:41 pm »
we could have a topic showing equivalent commands.
it could just be like this, but perhaps more organized and alphabetical: Old__________New Conj() | Copy() Repeat | Until Tangent() | Bitmap() int() | sign{} Fill() | Zeroes() ________________________ you'd want two tables, one for alphabetical Old commands, and one for alphabetical New commands. 1136
TI Z80 / Re: Project... i'll need help« on: June 17, 2010, 06:01:35 pm »
touche. this is not basic. squaring makes the code larger by 35 bytes.
1138
TI Z80 / Re: Project... i'll need help« on: June 17, 2010, 05:42:12 pm »Code: [Select] If X<95 and getKey(3):X+1->X:sub(A):End can be Code: [Select] If X>0 and (X<95 that way you're only calling the subroutine twice.. because think about it, all four of your if-conditionals have the possibility of being true simultaneously, so you'd be calling the subroutine A 3 unnecessary times. Code: [Select] While getKey(29) and (G=29):If L>1:L-1->L:Text(1,0,L|>Dec):Pause 125:End:End can be Code: [Select] While L>1 and getKey(29) because if L is not greater than 1, nothing in the while loop happens and is therefore useless, so i put L>1 as a conditional for the loop to be checked against. however, if you want getkey(29) to halt program execution even when L<1, my optimization is useless. Similar optimizations can be made to the while loops nearby that section in the code. 1139
The Axe Parser Project / Re: Bug Reports« on: June 17, 2010, 04:49:33 pm »
that doesn't make much sense to me, but thanks. that may be what's been causing my problem for all this time too
1140
The Axe Parser Project / Re: Bug Reports« on: June 17, 2010, 04:42:09 pm »
Axe doesn't detect whether the arguments for Fill() are in the correct order.
0->{L1} Fill(200,L1 compiles, but if you run it it'll give you a ram clear. |
|