On Thu, Sep 5, 2013 at 11:40 AM, Chris Warburton <[email protected]>wrote:
> to prevent type errors like "true 5 +" it uses a different stack for each > type I think these errors might not be essential to prevent. But we might want to support some redundant structure, i.e. something like 'genes' where multiple agents contribute to a property, such that if some of them error out they don't ruin the entire model. If we think in terms of a code-base, consider each sample in the population having two definitions for each word in the code-base. Each time we use a word, we apply both definitions, and if one of them doesn't make sense we discard it; if both make some sense, we combine the results in some simple way. The 'words' in this case would be like genes, and we could easily model sexual recombinations. Usefully, we could also model hierarchical 'stages' such that lower-level words use primitives, but higher-level words use lower-level words. This would allow us to scale upwards: codons, proteins, organelles, cells, organs, etc. Anyhow, there are a lot of directions we can take such things. Avoiding type-errors isn't the main issue; I think keeping it simple and supporting some redundancy is much more useful. But favoring a simpler programming model - e.g. one with only integers, and where the only operation is to add or compare them -might also help. > > many languages designed for genetic programming > actually get rid of errors completely (eg. by skipping nonsensical > instructions); I see. If you want to avoid errors completely, it is always possible to ensure consistent input and output types for each named 'gene' or 'codon', while allowing many implementations. The lowest level genes or codons could be automatically generated outside the normal genetic mechanism (using brute-force logic to find instances of a type), and occasionally injected into a few members of the population (to model mutations and such). Best, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
