Code center > Suggestions
Evolving Reproduction
EricL:
Right now, a bot must not only evolve a .repro sysvar followed by a store in order to reproduce, but must also store a positive number into that location. That is
407 .repro store
will result in reproduction but
-407 .repro store
will not. The code currently ignores reproduction requests where a negative number is stored into .repro.
Additionally, the current code treats any number above 99 as 99. Thus
407 .repro store
is equivalent to
99 .repro store
This is one reason the phenomem of bots giving 99% of their nrg to their offspring is such a common occurance in evo sims. Evolving it is 320 times more probable then evolving reproduction using some percentage other than 99%.
I would like to change both of these such that stores of negative values to .repro result in reproduction and stores of values >99 are MODed 100. The result would be that storing any non-zero value into .repro would result in reproduction and there would be an equal evolution probability for all reproduction percentages.
Comments?
shvarz:
How about making it circular? So that 101 .repro store is the same as 1 .repro store Seems more fair to me...
As for negatives we can either ignore the sign completely, or set them to 0. Or (here's an idea!) set off a timer during which the bot cannot reproduce even if a positive number is stored into .repro So that -20 .repro store would mean that bot cannot reproduce for 20 cycles no matter what. This kind of thing may be useful for something like multibots where a delay in reproduction is needed.
Numsgil:
Eric, I have a slightly alternative suggestion, but it breaks backwards compatibility. Most sysvars have a domain or range in the [-1000, 1000] range. I would bump the reproduction values from 1-99 to 1-999, and then mod the values.
But again, this breaks backwards compatibility, so it's probably not something to add at the moment.
EricL:
--- Quote from: shvarz ---How about making it circular? So that 101 .repro store is the same as 1 .repro store Seems more fair to me...
--- End quote ---
This is precisely what MODing means and is precisely what I am suggesting...
--- Quote from: shvarz ---As for negatives we can either ignore the sign completely, or set them to 0.
--- End quote ---
I like equally out the probabilities, so I prefer to ignore the sign.
--- Quote from: shvarz ---Or (here's an idea!) set off a timer during which the bot cannot reproduce even if a positive number is stored into .repro So that -20 .repro store would mean that bot cannot reproduce for 20 cycles no matter what. This kind of thing may be useful for something like multibots where a delay in reproduction is needed.
--- End quote ---
Assinging a waiting interval between reproducing or a cost to reproducing too soon has been discussed recently elsewhere and I view it as a separate issue to this question, which is laser focused on the domain of mutations which can result in valid reproduction DNA. I like where you are going, but I see it as a separate discussion.
EricL:
--- Quote from: Numsgil ---Eric, I have a slightly alternative suggestion, but it breaks backwards compatibility. Most sysvars have a domain or range in the [-1000, 1000] range. I would bump the reproduction values from 1-99 to 1-999, and then mod the values.
But again, this breaks backwards compatibility, so it's probably not something to add at the moment.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version