swarm-modeling
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Swarm-Modelling] lifecycle requirements


From: Scott Christley
Subject: Re: [Swarm-Modelling] lifecycle requirements
Date: Thu, 30 Nov 2006 10:51:44 -0500


On Nov 30, 2006, at 1:49 AM, Marcus G. Daniels wrote:

Scott Christley wrote:
This is often call the state explosion problem, and it becomes a problem when state change is more than changing the value of a variable but implies functional change as well. If you design a model where you explicitly handle all of those states, that means you need to explicitly write code for the function of the agent for each states. What if the number of states is exponential?
I think that's overstating it a bit. A larger space means more things are possible, but the interpreter of that space can still be simple. A codon is simple and stable in spite of the fact a larger genomes can code for more complex things. Similarly, the instruction set of a CPU is small and finite and relatively straightforward to get working compared to the virtually infinite number of programs than can be written with that set of opcodes.
This might be no big deal, but another complexity is that under different circumstances, the splicing process produces different RNA. So the basic idea that a single gene (DNA) produces a single Protein is not true, there are multiple proteins produced through alternative splices.
Ok,1) the notion of alternatives and 2) information about how to regulate the alternatives
In biology, a protein's function is defined by its structure but that structure is not fixed, enzymes and other molecules often change that structure, so a protein is considered to have different conformations.
and 3) context dependency
Now you are faced with a scenario that the hyperspace is so large that you cannot code in all of the possible interactions ahead of time.
But it's mainly about computer runtime not human time (e.g. too many coding details).

I don't think I explained my point properly because it is an issue of human time, and the desire to move more of that human time to computer runtime. Maybe "states" is too ambiguous because I'm not thinking of states as you mention above with codon. Take the CPU example, where the instruction set is not small and finite, imagine a CPU where the instruction set is not completely defined, where there can be a large or infinite number of opcodes which may be defined on the fly. Though, this doesn't increase the theoretical "power" of the CPU; it does increase it expressiveness. Attempting to predetermine all of the "useful" opcodes would require considerable human time, so try to convert it to computer runtime.

Then again, the notion of the instruction set gets pushed to the meta- level, so instead of talking a finite instruction set, you end up talking about a finite number of meta-instruction set rules, i.e. rules which produce instruction sets.

Scott






reply via email to

[Prev in Thread] Current Thread [Next in Thread]