I had similar thougts about PIPE. Yet there is no difference between a particle map and a matrix. Technically a particle map IS a matrix and in fact I too would have only stored pointers in the matrix anyway.
About the energy particles: Wouldn't it be way smarter to restrict to a maximum of one particle per position ("pixel") and use some other way to calculate the enery particles?
Instructions to compile a file using the SDK:
Change into the directory you have downloaded the SDK. The assembler is called "tptc" and requires python 3 to run. To get help with TPTC just call it ("./tptc" or "./tptc --help" on UNIX). To compile the first tutorial that ships with the SDK type "./tptc examples/tutorial\ 1.tpts". TPTC will then output some information and produce a file called "tutorial 1.tptb" in the "examples" directory. This is a pseudo-binary, that can be imported into TPT by using the "import.lua" script in the SDK. This script expects your binary to be located in your ".powder" directory and named "import.txt". Issue "dofile "import.lua" in TPT's console to invoke the import script.
Note that you will need a UNIX-like operating system for TPTC to work. It might work on MS Windows by using Cygwin, but I haven't tried.
That's simply the optimal way of guessing your number. You could always try to overclock the thing to make it guess faster, though I have no idea how the clock signal is generated.
Technically what this computer's program is doing a 'binary search' of what your number might be. You may think that the computer is taking forever to guess, but what if the range for your input were in the million's. The binary search algorithm given that you keep telling it 'higher or lower' at most (worst case algorithm performance) would ever have to make up to O(log_2(n)) guesses to find your answer while the 'random guessing' you are suggesting to do theoretically would at most involve 'randomly' guessing non-consecutively out of a list of one million possibilities. Given the binary search implemented in this save, if you were given a choice of a number between 0 to 1023, the most number of guesses the computer would have to make is 10. This is because 2^10 = 1024 or the logarithm base two of 1024 is 10. On the other hand using your random generation of guesses could take up to 1024 guesses. And if you don't 'cross out' guesses you've already made, it could take theoretically an infinite number of guesses before it ever gets it right.
That's why the implementation drakide provided for 'guessing' your number is in fact one of the fastest. http://en.wikipedia.org/wiki/Binary_search_algorithm. Binary search is essentially a way to 'narrow' down the number by putting your number into an ordered list of integers within a range and continuously 'halving' the list it has to search through until it finally 'lands' on your number when jumping to the _middle_ of its current list. Initially the computer would have had 1024 choices, but once you said it wasn't 512 let's say and it was higher or lower, you just cut the number of integers it had to choose in two; 512 possibilities now. Let's say you said it's lower, then it will only have to check between 0 to 511. Taking the half point, if you still say it's not 127 by higher, the computer only has to search from 128 to 511 which has 127 possibilities. This goes on and on until it finally finds the middle of a 'half interval' and you say it guessed it right.
In fact in real life numerical guessing games, if you have the option to limit their range and ask for higher and lower, ALWAYS use a binary search to close in on the range that there number may be included in.
Regards,
Schmolendevice
its not just for guessing the numbers its a programable computer with a guessing number program written in as an example, its other uses could be endless, so its defiantely not overcomplicated if not quite simple and small for a computer of it capability