Omnimaga
Calculator Community => TI Calculators => Grammer => Topic started by: persalteas on May 12, 2013, 12:44:49 pm
-
In this (http://tiplanet.org/forum/viewtopic.php?f=9&t=11837) TI-Planet topic (reading not required), we were making comparisons between Basic and Axe means to make a laser rotation like this:
(http://img.removedfromgame.com/imgs/angularLaser.gif)
I wanted to try to do this in Grammer, because it combinates the speed of Axe and the lightness of Basic :P
But, as Grammer has no "Degree" mode, i did not manage to make it.
My code looks like this, now: (I added a patern to the line for fun)
:.0:Return
:0->A
:1->B
:ClrDraw
:Return->Z
:A+1->A
:call Lbl "D
:Text('0,0,A
:DispGraph
:Pause 10
:B=0:->B
:call Lbl "D
:Goto Z
:.D
:Rect('47,31,47+100*sin(A),37+100*cos(A),B+4,,2
:End
And... it works not. Can you explain me why ?
Thanks
-
Could you say what the problem is ?
-
sin() and cos() in Grammer are basically the same as in Axe. It returns a value from -127 to 127, so when you multiply by 100, it goes way off screen. Here is my rendition:
.0:Return
0→A→E
Repeat getKey(15
ClrDraw
IS>(A ;just to increment A
Text('ºA and 255
62+sin(A
/ 2→B
94+cos(A
/ 2→C
Line('47,31,C,B
Line('48,31,C+1,B
Line('47,32,C,B+1
DispGraph
End
Stop
-
Thanks !
I don't understand your code, but thanks, that will be very good enough ! :)
-
I say : mine is still faster, you've lost Persalteas :P and it'll be even faster when I'll insert it in IkarugaX's engine.
-
I remind you that the initial debate was not on the speed but on the size of the program.
-
You can't compare program size between Grammer and Axe. Axe and ASM okay, but not Grammer and Axe.
-
I destroyed this argument on TI-Planet's subject, Matrefeytontias.
-
I mean, for one program, this program --' you know what I mean.
-
I destroyed this argument on TI-Planet's subject, Matrefeytontias.
Also, you destroyed nothing, we told you about Fusion.
-
Also, you destroyed nothing, we told you about Fusion.
Fusion or not, I replied that the program has a size 2.5 times bigger, not having taken into account the 200o routine. Here : https://tiplanet.org/forum/viewtopic.php?f=9&t=11837&start=20#p140370
-
That is because Fusion is not developped at its true potential. Its goal is "even more speed", not "even less space", because using it takes less time to compile. But if Fusion was made very efficiency, it would be another story. But it will never since Fusion is mostly for developers and not very much used.
-
That is because Fusion is not developped at its true potential. Its goal is "even more speed", not "even less space", because using it takes less time to compile. But if Fusion was made very efficiency, it would be another story. But it will never since Fusion is mostly for developers and not very much used.
I don't mind the cause of that, the essential is that it is a fact. Grammer's programs have a size much less big that Axe's.
-
A strong suggestion: only use Axe fusion for testing your own programs, and not for programs you distribute to others. It's really underbaked and I've just barely been keeping it working in the latest Axe releases. I will likely remove it entirely eventually in favor of replacing it with a better, more robust system.
EDIT: And to clarify, the purpose of Axe Fusion was to result in smaller compiled programs. It was not intended to increase either compiling or execution speed.
-
That is because Fusion is not developped at its true potential. Its goal is "even more speed", not "even less space", because using it takes less time to compile. But if Fusion was made very efficiency, it would be another story. But it will never since Fusion is mostly for developers and not very much used.
I don't mind the cause of that, the essential is that it is a fact. Grammer's programs have a size much less big that Axe's.
Of course, since they are plain text that gets interpreted. Just try to compile a Grammer program in the ASM resulting of its interpretation and then we'll can talk.
-
Yeah, and ASM kills every other language, I already heard that song somewhere (also, not even since it has to have its own routines included in the prog, maybe more optimized than in Axe but still there).
There is not a language that is better than the others, there are advantages everywhere, but also drawbacks everywhere. Axe needs nothing to run but is "big". Grammer is "small" but needs the app to run. Basic is fast to write but slow to execute.
etc.
EDIT: And to clarify, the purpose of Axe Fusion was to result in smaller compiled programs. It was not intended to increase either compiling or execution speed.
Ah ? I thought it was about compiling speed. Yeah, can be useful too to have smaller progs if you have a lot of projects.
-
Of course, since they are plain text that gets interpreted. Just try to compile a Grammer program in the ASM resulting of its interpretation and then we'll can talk.
Did you only read this post ? https://tiplanet.org/forum/viewtopic.php?f=9&t=11837&start=10#p140313
Bien sûr que si que ça sert de comparer, on présente souvent la page d'application Grammer nécessaire pour exécuter des programmes Grammer comme un inconvénient, il est donc juste de montrer que les programmes sont d'un autre côté bien plus légers et qu'avec pas mal de programmes, la balance penche bien vite du bon côté.
-
EDIT: And to clarify, the purpose of Axe Fusion was to result in smaller compiled programs. It was not intended to increase either compiling or execution speed.
Ah ? I thought it was about compiling speed. Yeah, can be useful too to have smaller progs if you have a lot of projects.
Yeah, programs compiles within the same time, but there aren't several hundreds of bytes that gets suddenly added when you reach 100% of the first pass.
-
Of course, since they are plain text that gets interpreted. Just try to compile a Grammer program in the ASM resulting of its interpretation and then we'll can talk.
Did you only read this post ? https://tiplanet.org/forum/viewtopic.php?f=9&t=11837&start=10#p140313
Bien sûr que si que ça sert de comparer, on présente souvent la page d'application Grammer nécessaire pour exécuter des programmes Grammer comme un inconvénient, il est donc juste de montrer que les programmes sont d'un autre côté bien plus légers et qu'avec pas mal de programmes, la balance penche bien vite du bon côté.
Yeah, so everyone codes in Basic, that is the language that saves the most space. You don't even need an external app to start saving space, the OS runs them natively.
-
Yeah, so everyone codes in Basic, that is the language that saves the most space. You don't even need an external app to start saving space, the OS runs them natively.
You're twice wrong : Grammer's programs are faster AND more light than TI-Basic's ones.
-
Overall, the one thing I like best about Grammer is that you can make programs as quickly as you can in BASIC. If you test the program and you need to change something, just press ON to break the program, edit the code, and run it again-- no need to compile the source. It is also why I like programming in hexadecimal. It is often more efficient for how quickly you can program something.
However, if you need something to be really fast, I would go with Axe since it is highly efficient and a lot faster to code in than Assembly (if you are used to Axe).
-
Overall, the one thing I like best about Grammer is that you can make programs as quickly as you can in BASIC. If you test the program and you need to change something, just press ON to break the program, edit the code, and run it again-- no need to compile the source. It is also why I like programming in hexadecimal. It is often more efficient for how quickly you can program something.
However, if you need something to be really fast, I would go with Axe since it is highly efficient and a lot faster to code in than Assembly (if you are used to Axe).
Yeah, I know all of that, and I have nothing against Grammer (also, if Grammer gets ported on the CSE before Axe, I'll use it instead ;)), I was just telling mdr1 that his arguments were not good.
-
Yeah, I know all of that, and I have nothing against Grammer (also, if Grammer gets ported on the CSE before Axe, I'll use it instead ;)), I was just telling mdr1 that his arguments were not good.
Well, if you could answer to my last post, it would be really great ! ;)
My arguments are that Grammer's programs are really light, enough to make profitable the 16,384 bytes used by the application when we begin having enough programs, and that Axe's programs are faster. Which is wrong ?
-
None of those assumptions are false. But the first one doesn't apply since Grammer programs are not in a high number (don't know why btw, Grammer has as much potential as Axe, maybe just because it came after Axe).
-
None of those assumptions are false. But the first one doesn't apply since Grammer programs are not in a high number (don't know why btw, Grammer has as much potential as Axe, maybe just because it came after Axe).
Of course. And this is a point to improve Grammer's programs number. It's like libraries : an enough number of programs is required to make it usefull for memory space.
-
BASIC programs are smaller than Axe, but the data they use is horribly massive. This is why in many cases a BASIC game will end up way larger than its ASM counterpart.
-
BASIC programs are smaller than Axe, but the data they use is horribly massive. This is why in many cases a BASIC game will end up way larger than its ASM counterpart.
Yes ^ I wish we had a way to make a parser hook that could read archived variables and compress variables to other formats. For example, if you have a list of only integers 0 to 255, it could cut the list size to 1/9.