Code center > Suggestions
Evolving Reproduction
EricL:
FYI, I am deblibertly suggesting that multiples of 100 are in fact equivalent to 0. Thus 641 out of the 64001 possible values that could be stored into .repro would not result in reproduction.
Numsgil:
--- Quote from: EricL ---The domain of sysvars is [-32000, 32000]. Mutations to DNA values which get stored to sysvar values will range in this range. I understand what you are saying in that the domain of vaues that actually do something interesting is often much more limited depending upon the sysvar. My goal is to address that for this sysvar and in the future for others.
I'd prefer to treat the question of adding more granularity to sysvar operations and the question of what percentage of mutations result in valid sysvar actions (and the probability distribution of mutating those values) as two separate issues.
Your suggestion of increasing the granulatiry for the .repro (and .mrepro) sysvar(s) so that bots can give offspring 50.8% of their nrg for example where today it must be 50 or 51 may be desirable. Certainly I would not be opposed to it but for the backward compatability issues but to be honet, I don't really see it as that critical. Yes, what you suggest has the side effect of increasing the percentage of mutations that result in DNA that does something, but I view the Abs and the MOD portions as much more important that the increased granularity and I think would prefer to do those without changing the granularity and breaking backward compatability.
--- End quote ---
I like modding, absoluting, and clamping values to ensure that as many things as possible do something. What's I'm proposing is for a next generation DNA specification, with old DNA either being deprecated or mutually supported. At present, here are the sysvars that operate in the -1000, 1000 range:
Movement (.up, .down, etc.)
Turning (actually it's 1256, but I'd like to move it to 1080 as was suggested a while ago) and angles (and there are alot of sysvars in this category)
Positive Shots
Memory locations
Tie Length
And other sysvars, such as eyes, etc. return and use values in a smaller range in the 100s, so I'm toying with the idea of "Upgrading" and redefining alot of commands, sysvars, etc. to work in the range -1000, 1000.
The physical memory would still record -32000 to 32000, but I think standardizing the domains and ranges of sysvars into a smaller and well defined range would make things a little more interesting.
In the end, I think this is one of the fundamental limitations about evolution, with very real implications to real world biology. The numerical systems ALife uses has all sorts of problems, as we've found out. Evolution is terrible at finding exact values. Real biology probably figured this out a while ago, and doesn't work in a way that's isomorphic to the system we or most other alife systems work, specifically because the exactness of numbers is too difficult to figure out. Real evolution probably works as a balancing act between competing genetic forces.
EricL:
Cool. I agree with everything you say here, especially the comments about the descrete nature of DB and its relationship to more 'analog' biological systems. When we make the big break from the past and break compatability, I'll all for adding additional sysvar granularity.
I think for this imminent drop however, as you say, we should not make such a break. I will however, add the mod and abs(). In fact, I already have.
Jez:
Equal probability of different repro values being evolved sounds cool to me!
I also like the sound of the direction the ideas for DBv3? are heading, even if it is going to cause enormous problems for old bots.
Numsgil:
Thanks.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version