Cellular automata apply the same rule across a grid, a bitgrid is an array of lookup tables, essentially stuffed between the cells of a static RAM. The RAM holds the values in the tables, and an latches maintain the state of each cell's inputs. Thus each cell in a bitgrid is individually programmable.
A provision needs to be added to be able to read and or write (override) inputs for debugging or other purposes, such as testing, updating constants, etc.
I agree that formalization is required. I've built an emulator, and hand coded some logic into it as a test, and can simulate a 1024x1024 grid at about 35 Hz on my desktop pc (half that on my laptop).
My near term goals are to be able to take an expression, run it through a set of tools to be written, and then feed it into the simulator, and run it.
I can guess at the energy required to change states, and thus get a rough estimate as to power usage/efficiency/speed, etc. If I get myself to the point where I've got a chip designed, I'm sure the EDA tools can give me far more accurate numbers.
Oh, I meant formalization as in, this is clearly not either a turing machine or a lambda calculus, but as it appears turing-complete, it must be equivalent, and could benefit from formalization in that computer-science/mathematical sense. Then we outsiders would be able to see what we're looking at.
You could consider a BitGrid to be a giant state machine, given any current set of inputs, and the program loaded into it, it is possible to know exactly what the next state will be. The connectivity turns it into a complex system. The number of possible states is somewhere between 1 and 16^cellcount
I'm not sure that it's possible to compute (in a reasonable amount of time, or maybe ever) the exact number of possible states a bitgrid may have, given its current program.
It's my conjecture that finding this exact number is equivalent to solving the halting problem.
---
Also, any computation in a Bitgrid is an acyclic directed graph. Because there is a delay between cells, you can only effect future states.
A provision needs to be added to be able to read and or write (override) inputs for debugging or other purposes, such as testing, updating constants, etc.
I agree that formalization is required. I've built an emulator, and hand coded some logic into it as a test, and can simulate a 1024x1024 grid at about 35 Hz on my desktop pc (half that on my laptop).
My near term goals are to be able to take an expression, run it through a set of tools to be written, and then feed it into the simulator, and run it.
I can guess at the energy required to change states, and thus get a rough estimate as to power usage/efficiency/speed, etc. If I get myself to the point where I've got a chip designed, I'm sure the EDA tools can give me far more accurate numbers.