Calculator Community > Grammer

Conway's Game of Life

<< < (2/3) > >>

Xeda112358:
:D Awesome! I was really really tempted to just add CGOL as a Fill( command, but I wanted the fun of coding it in Grammer. I felt like I would be ripping you off if I just added a command, but I really like the idea of UnD. Would you be okay with me really adding the command? I would make it just a general 2D cellular automata like my program used (which has a rule for CGOL).

Anyways, for the prime sieve, I made it in both Grammer and TI-BASIC using a similar idea. The main difference was that Grammer automatically splits up the remainder and whole value and uses a 64*96 screen. So in Grammer, I figured it had 96*64=6144 pixels to work with. So the highest prime you would need to factor out would be 73 (square root of 6144 is 78, the next lowest prime is 73). So the code:

--- Code: ---Fill(0
For(A,2,73
If pxl-Test(0,A
Then
A+A→C
0→D
For(B,C,6144
If C>95               ;for wrapping to the next line
C-96→C:D+1→D
B+A-1→B            ;we want to increment every multiple of A and For loops will add 1 automatically
Pxl-Off(D,C
C+A→C               ;get next increment
End
End
DispGraph
End
Stop

--- End code ---
This will result in black pixels representing primes (except for 0 and 1 which stay black, though they are neither prime nor composite). Of course, there is the command >Frac that can be used to test if a 16-bit number is prime or not, but that also takes out the fun of a sieve :D

awalden0808:
Totally. I know that making it with Grammer is possible, and we both have done it (well, I need to get that buffer storing thing figured out first). So next step is speed. Yes, do it!

How are you going to include other cellular automata?

And wow. That prime sieve is a literal sieve. It take a big pile of numbers and takes out all of the primes. Mine takes one number at a time and sees whether or not it fits in the holes (of the sieve :P).

So what good does it do to have the numbers on the graph? Will you then use a second program to figure out which number each corresponds to, then store them to a list? Or is there no purpose, just to say you did it? Or a test for a programming language?

EDIT: I don't know why but I've never been smart enough to just say "If pxl-Test(A,B" instead of "If pxl-Test(A,B)=1". Cool! New memory saving technique!

Xeda112358:
Pretty much, my program works like this to get other forms:
There Surviving, Rebirthing, and Dying conditions based on the number of live pixels. Since there are at most 8 pixels, I can use 9 bits (for zero as well). If surviving is S, rebirth is R, and dying is Q:
S=4 (000000100b)
R=8 (000001000b)
Q is computed by using not(R or S

So if there are 3 pixels around, I do 2^3 to get 8 as a mask. "8 and R" returns nonzero, so I know it gets reborn. That, by the way, is CGOL :D
The main problem is that I haven't released the Grammer version with e^( which computes 2^n, but here is the code:

--- Code: ---If Q and e^(H        ;H is number of pixels around the cell
Pxl-Off(A+1,B+1,Z
If R and e^(H
Pxl-On(A+1,B+1,Z

--- End code ---

EDIT: Back from class, I didn't see your edit D:
So, for the sieve, you can pixel test a number to quickly figure out if it is prime :D It only works up to 6143, though :/

Also, for a few other memory saving techniques, you can try using If !pxl-Test(A,B instead of If 0=pxl-Test(A,B

awalden0808:
Could you do me a favor and explain the graph buffer saving? I see that the pi symbol means hexadecimal, but what do the values correspond to?

Xeda112358:
The values are actually RAM addresses. The calculator has 3 buffers the size of the graph screen (768 bytes).

pi9340 is the graph buffer that the OS uses

pi86EC is a 768 byte buffer that Grammer makes use of for temporary operations and whatnot. You are probably safe if you use this to very temporarily store a screen here or something. It gets used by text conversion routines and I believe that is all, now. I have been trying to make Grammer not use this buffer, so I will have to rewrite the text display routine. Pretty much, if you want to use this, you can probably start at pi87EC and be safe with 512 bytes of RAKM there

pi9872 is AppBackUpScreen. At the moment, Grammer initialises this with the first two bytes for the particle buffer. If you are not using the particle routines or you have set your own buffer, you can use this with no problems.


Also, I am about to test my first attempt at a 2D cellular automata as a Fill( option. I am sure it won't work this time, but if it does, I am hoping for 6 to 8 FPS in 6MHz (though it might be much slower :/).

EDIT: Yeah, my anticipations went a bit too high :/ it didn't work, but I am sure it only needs minor adjustments. It only gets about 2.3 FPS at 6MHz and about 6FPS at 15MHz :/

Navigation

[0] Message Index

[#] Next page

[*] Previous page