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.
Messages - Xeda112358
Pages: 1 ... 62 63 [64] 65 66 ... 317
946
« on: May 18, 2013, 07:50:14 am »
I am thinking really hard about how to handle math. I can definitely make it handle order of operations, but it would be a little slower.
947
« on: May 17, 2013, 09:03:15 pm »
That is spectacular, thank you, Adriweb o.o @ruler501: I believe that the defining characteristic of the Gamma function (the one that makes it unique) is that its concavity is always up. There are infinitely many functions that satisfy the other traits, but once you have a function that satisfies those and is concave up, it must be the Gamma function. Evidently, I need to see where I have the difference of two ratios wrong  Again, thanks!
948
« on: May 17, 2013, 05:50:26 pm »
As it currently is, just having labels and variables pre-parsed saves a lot of time and having numbers pre-parsed saves a lot more time. For example, Grammer 2 takes nearly 70 t-states for each digit extra in a number, but Grammer 3 takes 13 t-states for every 8 bits. For comparison, 65535 takes about 350 t-states for Grammer 2 to read and convert, and only 26 t-states for Grammer 3. While it still won't be as fast as Axe, it will still be faster than Grammer 2. The other thing that I am now trying to figure out is how to make math much faster, but I always worry about that. I have one more random thing before I finish this post. I just put together a quick example program in Grammer 3 and the size of the code and variables together is 80 bytes. The equivalent in Grammer 2 is 86 bytes (not including the header), so there is some small size savings there. I might have an active screenshot in the next few days if I don't get distracted again. I got a book last night and read it and I got distracted by lots of math stuff >.> EDIT:@codebender: Well, you will be able to write and define functions in Grammer code  However, command set extensions will need to be written in assembly. EDIT2:Well, I threw together a quick example of a Grammer 2 program and a Grammer 3 programand you can't see much of a difference (though it is approximately 20% faster). I am hoping that when I optimise the code for the new syntax, it will get a little more speed. Also, I have math reading left to right, now that I don't have to worry about the issues that math had in Grammer 2. This means that math should be faster and use less stack stuff than Grammer 2. I also still have to update the sprite drawing routine to use the better one in BatLib (which draws large sprites, clipped, and possibly faster).
949
« on: May 17, 2013, 03:09:48 pm »
Oh, the whole code is being preparsed. Are you saying, for example, to compile some parts of code directly to assembly?
950
« on: May 17, 2013, 11:08:55 am »
I wanted to show you one result from my work over the past two days, since it lead to some neat derivations. Essentially, it is an approximation that converges to the gamma function. I know, it isn't that awesome, but I had fun Attached are some computation thingies, too, if you wanted to look at it.
951
« on: May 16, 2013, 05:37:38 pm »
Cool ! Will the app support variables' declaration with the type ? And what about local variables ? Will we be able to do recursive functions ?
Well, for example, if you start typing with a ", the parser automatically pastes another " and an un-named string variable will be created. You can go into the vars menu (or press a specific button) to name the string. For other variable types, you will have to create them in the variable menu. For example, sprites will need a width and height associated with them, so you will need to input that. Local variables are going to be just variables that are stored with the file, so it isn't like real "local variables." Instead, you can pass arguments to other programs, you can define a global variable. For recursion, you will probably want to use the stack functions which will allow you to push/pop variables. Why not put the most needed functions in the 1-page app parser, and then put other functions into several appvars which would be used like the DLL ? Programs needing such a appvar would require it, and even though the user would use all the functions, the final size woudn't be 16 kilo bytes. Of course, updating would be more difficult... I could possibly do that, but it is a lot more difficult to read and execute code from an appvar. As well, it is slower, since I would have to locate the appvar, find the specific code, copy it to RAM, then run it. (As opposed to 'find the code, run it'). Finally, a 2-page app isn't so big when be think about Omnicalc and so. And the containing of an editor could appeal users of programs and give them curiosity to try to do something. Will you introduce hooks like the OS to customize the editor, like adding tutorials as you did ?
Hooks are definitely a planned feature. There will not be a parser hook since you will be able to load custom command sets, but getkey hooks, font hooks, and token hooks would be a great idea. Custom fontsets will be available, as well as token sets, but this might be useful for different languages. It's not really a good idea to my mind, because we couldn't see the difference between pictures which don't have any pixel on on the board up left.
Hmm, maybe I should display the whole thing, then? Either way, you would still be able to select it to open up a larger view. Will you add the support of tilemaps and an editor of tilemaps ? Will you add a basic pictures compression ? What about gray-scale sprites ?
Tilemaps will be supported and my hope is to have a similar editor. There will definitely be compression routines for pictures and text, and I have been trying to figure out how the grayscale editor will work (for sprite editing), but there will still be grayscale (at least 3 and 4 level). Please don't, it is usefull the first 5 minutes, but then we know the keys and don't need their action's description to be shown anymore, and a line of code is removed. Okay, I will just leave that to the readme, then Yes, and I've been waiting for those two years ! And hope you'll finally do it ! 
Me, too  NB : know that you're doing a 2-pages app, will you be able to add a command to parse pieces of code as someone proposed it ? But after having finally done this version 3 for sure.
I am not sure what you mean, sorry .__. *Edit AOC* Fixed a typo. 
952
« on: May 16, 2013, 08:56:51 am »
Wow, the editor is EXACTLY as I dreamt it to be ! The sprites, the edition of variables' names... !!! 
I am glad you like the look ^_^ I am about to start coding some more, so hopefully I can make it work the way I envision it! For the Repeat command, it could be an bad point though, because the speed would decrease doing so.
It would actually still be fast since this is how Repeat loops are typically handled anyways. I am doing it this way because it will help to prevent stack overflow issues. Math might change, too, by the way. I am still working out how I want to efficiently handle math. I will probably attempt Order of Operations so you can do something like 3+6*(a+b 4) like you would in BASIC. I hope we'll be able to "compile" a program in order to delete variables' names so that the program has a smaller size.
This is an excellent idea and I was thinking about doing that. The way it is currently set up, it is very easy to separate the names from the program which could save a bunch of memory. As well, a few other tokens can be removed to save a byte here and there (and the source will still be able to be edited). And maybe could you do a 1-page application which doesn't have the editor but that can run Grammer programs ? Because 2 pages are a lot for persons who just want to run the programs...
I was thinking about this and I at first thought I might be able to make one app for the editor, and one app to run the program. However, I was going to add a lot more commands to Grammer 3, so the parser would still need 2-pages  Then you would have a 2-page app for running Grammer programs and a 1-page app for editing them. Instead, I will try to make it just 1 app that is 2-pages. I assume that bigger sprites will be given a name in order not to take all the screen's place. :p
If the sprite is too big, I will have it display maybe a 16x16 portion and if the user wants to use edit it, a special editor will open. I hope that the text "Program : TEST" will be removed to have one more code line.
That is a good idea. I will probably still stick menu options on the bottom row, though For example, 5 options for F1~F5: [Char][Set ][Calc][Copy][Exit] Char will let you access the character set (so the ASCII) Set will allow you to load an external command set. So if anybody makes a Physics package, for example, you can load the Physics commands and view the token set for that. Calc Will open up a calculator window so that you can run a simple computation like 3*47+6(7*  and paste the result into your program. Copy Will be for copy/paste stuff. Grammer 3 promises to be a really really good app. Thank's !
I hope I actually finish it! I have been planning for over two years now, so hopefully you will get a chance to finally use it!
953
« on: May 14, 2013, 05:11:47 pm »
Hmm, I was thinking about that issue. I was thinking of making it easy for the user to disassociate a particular instance from the rest with maybe a quick key or menu.
And thanks, Art_of_Camelot!
954
« on: May 14, 2013, 04:50:33 pm »
I am not familiar with Java or the terms "structured variables" and "objects with methods." However, maybe this will answer your question:
In Grammer 3, there will be a few variable types such as:
Sprites - These get stored at the end of the file and have a size automatically associated with them. This means that the sprite command will work like this: Sprite(ptr,Y,X,Buffer)
Strings - These will have two forms, ASCII or Tokens.
Arrays - There will be a few forms such as fixed size arrays or the more flexible variable arrays (each element can be any variable type, including strings, numbers, sprites, or other arrays)
Integers - There will be signed, unsigned, and different sizes. Currently it only has 8-bit and 16-bit unsigned.
Fixed Point - These will be used for extra precision and will allow you to store numbers such as 2.3125
The actual details are really cool and I started working on the program editor earlier today. For example, the attached image (I made it in paint; it is not real) shows how sprites will be in-line and you will be able to directly edit them. But the really cool part is that the two sprites are the same sprite. Editing one automatically edits the other and any other instances of the sprite in the program. Here is how it works:
There will be local and global variables. Local variables will have a bunch of data stored about them within the program such as their name and the actual data. Local variables include labels, too. Each variable will have a 2-byte ID. When the editor reads the bytes, it will display the name of the variable if it has one. If it does not have a name, the contents of the variable are shown instead. In the editor, if you have highlighted the variable name/data, you will be able to edit the variable data (the program editor will know which var to edit based on the ID). So this means you can edit the name of the variable and all instances in the program will be changed automatically since it is only referred to by an ID. This also means if you use the same string multiple times, changing it in one place changes it everywhere else (as an example).
When running the program, if it is already in RAM, it will just be run directly. If the program is in archive, only the essential data will be copied to RAM. I am still trying to figure out what counts as 'Essential', though. Obviously the variable/label names wouldn't need to be copied since that is just for the editor. But as long as everything else is static data, I might be able to have Grammer keep the whole program in archive.
Oh, also, subroutines are a type of variable. For example, "Repeat " won't be a real command. Internally, it will just be stored as:
Lbl Repeat
Call Subroutine
If <condition>
Goto Repeat
But in the editor, it will look like a Repeat loop.
955
« on: May 14, 2013, 03:19:29 pm »
It is because of the OS version. On 2.43, it takes about 16 seconds, on OS 2.55MP it takes 21 seconds.
956
« on: May 13, 2013, 09:06:37 pm »
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.
957
« on: May 13, 2013, 08:51:41 pm »
Oh, it just uses a fairly simple trial division algorithm. I at one point uses a Fermat prime test modulo 2, but that algorithm is just too slow for anything smaller than 9 digits (in TI-BASIC it is, anyways). While it can return if a number is prime many times faster than trial division, it tends to be much slower than trial division at returning whether or not a number is composite (which is most numbers). So in the end, I found that it saved time to just remove the code for the Fermat test.
So instead, since all composite numbers except 2,3,5 are of the form 30k+{7,11,13,17,19,23,29,31}, I just check to see if any of those numbers are factors of the number up until the square root. The relevant code is:
If min(remainder(C,{3,7,11 ;Check primality
Then
√(C→D
{13,17,19,23,29,31,37,41
While max(Ans)≤D and min(remainder(C,Ans
Ans+30
End
N-not(not(min(remainder(C,Ans→N
End
958
« on: May 13, 2013, 08:46:55 pm »
I typically avoid using commands specific to the MP OSes, but since it was for a contest where speed was required, that is what I used. However, for those that want the version useful on all OSes:
:DelVar EAns-5→N
:While 1
:E+1→E
:1+int(log(E→B
:If 1<gcd(10,int(E10^(1-Ans
:End
:10E→F
:E→D
:While iPart(D
:.1iPart(D→D
:10(F+fPart(Ans→F
:End
:For(H,0,9
:If fPart(F/3
:Then
:√(F→D
:7
:While Ans≤D and min(fPart(F/Ans+{0,4,6,10,12,16,22,24
:Ans+30
:End
:N-(Ans>D→N
:If not(Ans
:Return
:End
:End
:F+10^(B→F
:End
:End
And it takes 70 seconds for the 100th (as opposed to 52 seconds) and 16 seconds for the 42nd (as opposed to 13)
959
« on: May 13, 2013, 08:43:21 pm »
So here is my palprime program, but after seeing Jim Bauwens' program and seeing that it could be tweaked to be much smaller and faster than mine, I don't know how much this is worth Ans→N
0
If N<1 or fPart(N
Return
If N<6
Then
{2,3,5,7,11
Ans(N
Return
End
N-5→N
9→B
1→A
While N
B+1→B ;generate the next palindrome
If Ans=10A
Then
Ans→A
Else
If not(remainder(B,A
1+B+A(1+2(B=4A→B
End
B→C
.1Ans→D
While iPart(D
.1iPart(D→D
10(C+fPart(D→C
End ;palindrome is in C
If min(remainder(C,{3,7,11 ;Check primality
Then
√(C→D
{13,17,19,23,29,31,37,41
While max(Ans)≤D and min(remainder(C,Ans
Ans+30
End
N-not(not(min(remainder(C,Ans→N
End
End
CFor timings, I got 14 seconds for the 42nd prime palindrome, 58 seconds for the 100th, 494 seconds for the 290th. Input is the 'nth' prime palindrome to return in Ans, and output is the nth prime palindrome (output in Ans).
960
« on: May 13, 2013, 08:35:02 pm »
So I tested yours and I got 21 seconds for the 42nd prime palindrome. Compared to mine, yours is 53 bytes less, too. You have a bunch of places that can be optimised for speed, though, so I tried a few things and here is what I have: First, here are the main optimisations I made: :If prod(Ans-{1,3,7,9
Goes to:
:If 1<gcd(10,Ans ;I actually used 'not equal', but this works, too
:If fPart(F/3
Goes to:
:If remainder(F,3
:While Ans{^2}≤F and fPart(F/Ans) and fPart(F/(Ans+2
Goes to:
:While Ans{^2}≤F and min(remainder(F,{Ans,Ans+2
There are a few more, too, but here is what I ended up with: :DelVar EAns-5→N
:While 1
:E+1→E
:1+int(log(E→B
:If 1<gcd(10,int(E10^(1-Ans
:End
:10E→F
:E→D
:While iPart(D
:.1iPart(D→D
:10(F+fPart(Ans→F
:End
:For(H,0,9
:If remainder(F,3
:Then
:√(F→D
:7
:While Ans≤D and min(remainder(F,{Ans,Ans+4
:Ans+6
:End
:N-(Ans>D→N
:If not(Ans
:Return
:End
:End
:F+10^(B→F
:End
:End
Now it takes about 17 seconds to compute the 42nd prime palindrome and it is 24 bytes smaller I have been trying to tweak it to get it even faster and I know that there must be a few optimisations that I am not seeing. It is 77 bytes smaller than mine and almost as fast, so that is really awesome. ... After adjusting the prime checker thing even more, I made it much faster, and it is now faster than mine, at the cost of some bytes (still 59 bytes smaller than mine). For comparison, the version above takes 17 seconds to find palprime 42 and 86 seconds for palprime 100. This version takes 13 and 52 seconds, respectively. :DelVar EAns-5→N
:While 1
:E+1→E
:1+int(log(E→B
:If 1<gcd(10,int(E10^(1-Ans
:End
:10E→F
:E→D
:While iPart(D
:.1iPart(D→D
:10(F+fPart(Ans→F
:End
:For(H,0,9
:If min(remainder(F,{3,7,11
:Then
:√(F→D
:13
:While Ans≤D and min(remainder(F,Ans+{0,4,6,10,16,18,24,28
:Ans+30
:End
:N-(Ans>D→N
:If not(Ans
:Return
:End
:End
:F+10^(B→F
:End
:End
Hopefully everything is typed properly. EDIT: Made it even faster. Now 12 and 49 seconds respectively, using the same prime checking routine as my program.
Pages: 1 ... 62 63 [64] 65 66 ... 317
|
Show Posts
