Code center > Darwinbots3

Bot DNA

<< < (2/13) > >>

googlyeyesultra:
I still don't like multi-threads. Can you imagine how hard it would be to debug a bot in? Not only would you have to check the last gene that had activated that referenced the misbehaving variable, but every single one that activated and referenced it (which, in large bots, could be a ridiculous amount). Does that also mean that 30 .repro store 70 .repro store will make 50 .repro store, even if done in one gene?

Numsgil:

--- Quote from: Trafalgar ---It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though, unless there's a command to toggle between the old and new behavior.
--- End quote ---

This is an interesting idea, I'll work through the consequences on paper and see how it would work.  Maybe every sysvar is just a command.


--- Quote ---I've been considering how to implement an antivirus for an evo sim without disrupting zerobot evolution. I was thinking a shepherd bot that would destroy any bots which are making viruses. The main reason is because virus-spreading isn't subject to mutation (as far as I know).

Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).
--- End quote ---

This is a really delicate area.  Viruses are probably one of the best features-- they work really well in both evo sims and battle bots.  But I think having a bot police its own genome is just too difficult and has too many problems.  I was talking with shvarz about it once, and he said that real organisms don't really have a method of dealing with viral infection other than dying so that the virus doesn't spread.

So I'm thinking that viral defense should be stronger, and internal methods of removing viruses (.delgene) removed altogether.  The effect is basically the same, and we can even make viruses easier to control as a weapon without overpowering them too much.

I might even make a way for a virus to convert its entire host into new viral particles and have them all explode out in a fiery explosion!  Hehe, woudln't that be a fun way to spread a virus


--- Quote ---If they run in parallel, coordinating numerous parallel code strands, making their conditions not conflict, and making them not fight over the same variables, would be a major pain in the ass.
--- End quote ---

I'm imagining that there's no communication between strands except if they write to the same sysvar.  If there's a conflict, I'd like to average the values.  The only problem is with sysvars that don't average well.  .shoot, for instance.  Which is why it's important to try and convert as many sysvars as possible to a system where averaging results in average behavior.


--- Quote ---This is essentially what SGizing is about, and with PyBot I can take it a step further.
I write this: setaim when (aim!=315) = 315
and it turns into this: 315 .setaim *.aim 315 sub sgn abs mult store
Which stores 315 into .setaim if *.aim doesn't already hold 315.

I also have almost all the stores in Guardian set up to only do the store if the variable isn't already set to whatever's going to be written to it. This slows down the sim further but reduces energy costs. Guardian is very energy efficient (except it splurges on movement speed and defenses) and very CPU inefficient (much of the reason is because the CPU inefficiency is necessary to make it so energy efficient).
--- End quote ---

I'd like to see SG methods become the primary supported method (it's how evolution likes to work, too), easier to read, and less hacky.  Maybe instead of storing to 0 as a free action, you can use some nice conditions that just happen to be inserted into the body of the gene.  I'm still working out how it would work.


--- Quote ---As long as the condition operators continue to cost energy, and regular math and bitwise operators don't, it would still be more (energy) efficient for bot authors to use SGizing instead of the actual condition operators. As for evolution, I'm not sure how to make it work better. It seems to me that it works fairly well as-is. Real evolution generally takes thousands of years or more to evolve new abilities (like eyes, or thumbs, etc).
--- End quote ---

Eric and I had a discussion a while ago about what sorts of DNA costs are good.  After reading through other simulators' code and forums, all signs point to the idea that you shouldn't charge bots for the length or complexity of their genome because you invariably favor shorter, stupider behavior.  I'd like to move to dumbing down the costs for DNA.  Just enough to prevent runaway genome growth that slows the program to a crawl.


--- Quote ---I for one use bitwise anding, both for SGized conditions, and for using a variable to store bitflags indicating what features in the bot should be toggled on.
--- End quote ---

You could also use memory locations for this.  I dunno, I do see some places where bitwise is good, but it just makes the DNA look too Greek.  And you can really produce the same behavior with other commands.


--- Quote ---What's really indecipherable is when an evolved bot is shooting and turning and crap, and there's not a single store or reference to .shoot in the entire DNA. It's powered by a simple 'angle inc' or 'angle dec' at the beginning of a start. (dist would work too)
--- End quote ---

Yeah, this is definately an issue.


--- Quote ---While it could be useful to have functions (I already do something similar, but it's really more like macros), I don't think allowing something like goto and gosub would be a good idea. It would encourage evolution to create utterly unreadable spaghetti code. I would much rather it be linear, at least then you can try to follow it in your mind.
--- End quote ---

I think a raw goto statement would be bad for this reason.  Within a codule, the program flow should be readily understandable.  Only when a codule gets to the end of itself should it pass full control to another codule.


--- Code: ---I'm not sure if this is a good idea or a bad idea. Wouldn't it make some bots slower, from every multiplication, division, etc, being performed on two numbers instead of just one?
--- End code ---

Speed isn't the primary issue.  I can probably even write some sort of DNA analyzer that trims DNA down when it's time to run it so you're not running junk.  My primary concern is with dot and cross products.  They both return scalars in 2D.  I guess I need to examine some existing robots and see how they would work if they were vectors.


--- Code: ---Having refveldn and the like be relative is already a pain in the ass, and having aimshoot be relative to your current angle is an even bigger one (since angle isn't, apparently). Making more things relative would not be a good thing, in my opinion.
--- End code ---

Wouldn't it be easier if everything was relative?  Then you wouldn't need to convert between absolute and relative.  It would be an entirely self consistant way of observing the universe.


--- Code: ---That would be nice. It would also be nice if it were possible for a bot to tell if another bot is shooting things by looking at .shoot (I've tried, it's always 0).
--- End code ---

That sounds reasonable.


--- Code: ---I don't think this is feasible in practice. For example, shootval with info shots.
--- End code ---

Yeah, I'm not sure how to address things like this.


--- Code: ---As for structure changes, it seems to me that the current structure works decently well. I'm trying evolution with zerobots with ridiculously large genomes now too, to see how that works out (15k, quite close to Guardian's size).
--- End code ---

It's alright.  Definately better than most other simulators where agents can only run X many commands per cycle.  But I think it can be improved to allow for some added complexity and features (sexual reproduction becomes alot easier if the DNA isn't quite so linear).


--- Code: ---I would suggest that info shots and memory writing with ties should set the variable after the rest of the cycle has run, so that on the next cycle, the bot can try to fix it if it is coded to. Right now they can instakill, and there's no way to stop it besides instakilling the attacker first.
--- End code ---

Yeah, this is definately an issue.  But if bots can override ties and info shots, then it makes them largely useless since a bot could just explicitly set every single sysvar.

Numsgil:

--- Quote from: googlyeyesultra ---I still don't like multi-threads. Can you imagine how hard it would be to debug a bot in? Not only would you have to check the last gene that had activated that referenced the misbehaving variable, but every single one that activated and referenced it (which, in large bots, could be a ridiculous amount). Does that also mean that 30 .repro store 70 .repro store will make 50 .repro store, even if done in one gene?
--- End quote ---

Threads wouldn't interfere with each other.  Only their end results would have any interaction.  And within a thread, it's as if the thread has total control of the bot.  So 30 .repro store 70 .repro store would result in 70 .repro store for that thread.  After all threads are executed, their final effects are averaged, but until that time a thread has no inkling of what other threads are doing.

googlyeyesultra:
Would this be a seperate command from goto and codules? If so, no further objections. I could live with it, and maybe use it from time to time. Still, having no ability to not use multi-threading when it doesn't serve a purpose well would be quite annoying.

Numsgil:
Yes and no.  I'm thinking that instead of a single root codule that calls other codules, you have several codules that are considered to be roots, with each starting it's own execution path.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version