Darwinbots Forum
Code center => Suggestions => Topic started by: Botsareus on July 24, 2005, 12:45:59 PM
-
I have an uneasy feeling that the junk dna in my and shvartz simulations will never stop building up until there will be some kind of overflow error....
Therefor:
-
First of all, you can't really calculate what is/isn't Junk DNA. It's just too complicated.
A better solution is to charge for DNA length, either as a continuous cost every cycle (maybe 10^-3 nrg per bp) or during replication.
Assuming of course that you see the Junk DNA as a problem. DNA can get up to 32000 elements long, and I have yet to see a bot that pushed that envelop.
-
Calculate length of all dna and put costs on replicating it.
Alright Ill be waiting for it...
-
Maybe increase the time required for replication based on size. This would probably affect the bots more than nrg requirements.
Endy B)
-
My own solution!
Allow junk DNA to just keep building up. We have no idea what is junk and what isn't anyway.
Robots are already charged energy to evaluate conditions based on the DNA length. Maybe just raise the default rate a little in the options panel.
-
LOL PY, did'nt I just say we will get overflows after like 1mill commands accumelate? Also think how slow the program is going to be. I mean [you]It will be nice [/you]to have infinate possebility , but even visual basic has its limits.
-
32000 elements is a hell of a lot of DNA. How long have you seen one get?
The size limit used to be 1000 and that was only rarely reached.
Also you can't overflow the DNA. It searches for available space before it allows any new values to be inserted. If there isn't room then it will not be added therfore no overflow.. ever!
As I said, it is already more expensive for robots with a longer DNA so should eventually reach a point where long ones will be selected against.
-
As I said, it is already more expensive for robots with a longer DNA so should eventually reach a point where long ones will be selected against.
not unless its all junk dna...
Ok Py , If you promise me no overflow error and I get one , you wont feel too good I gess... I will trust you on this, and resume my evolving.
My firstbot has 3621 (G6 almost shvartz method)
-
How about Ill do a MP?
Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it. Calculate length of all dna and put costs on replicating it.
There you go. Listin whats up in newbes posts...
:boing: Bau :boing: :shoot:
-
Calculate length of all dna and put costs on replicating it.
Not this again. :blink:
We have been through this before. Quite recently as I recall.
Read my lips.
It used to be done this way but we scrapped it because IT WAS CRAP!!
Here is why (again)
1) It is pretty near impossible to tell whether a new bot is created successfully (please let me know if you have a reliable way) when the .repro command is used.
2) When a robot has no space to reproduce but tries to anyway, repro will fail but he will still be charged energy for the attempt. This is stupid, unrealistic and sucks a lot!
3) This means that a robot in a confined space (say surrounded by veggies) is constantly feeding but his energy can never get above his reproduction threshold. When he tries to reproduce (like every cycle) a whole bunch of it just POOFs away into the nothingness of DB space.
It was just about the most annoying bug that I have ever had to work through. Loads of people reported the phantom energy loss. If we can easily get around the problem outlined above then it would be OK to do this. Otherwise forget it.
As for calculating the length of a robot's DNA. Not necessary! It is stored as a variable for each robot at birth and is changed only when he receives a virus or something that will adjust its length.
By all means charge a maintanence fee for powering the DNA on each cycle.
OH wait a minute! WE ALREADY DO
The conditions in the DNA are counted and a cost per condition is applied. The amount is adjustable from the options window!
Since it logically should not cost any energy for DNA that is not doing anything, junk DNA is then just dead weight. However if it isn't junk or if the supposed junk is in a condition step then it will be charged for anyway.
I really see this whole thing as a complete non-issue. I don't understand why you keep harping on about it.
-
Since it logically should not cost any energy for DNA that is not doing anything, junk DNA is then just dead weight. However if it isn't junk or if the supposed junk is in a condition step then it will be charged for anyway.
Perhaps it would be worth while to add a cost per base pair per cycle to the costs panel that defaults to 0. That would give the same result as charging for reproing larger DNA strands without all the mess.
-
No No , Py your bug is mood, look here.
1.) Before repoduction calculate if there is enough range to place a baby. Already works like that in PusherBots source code is attached to the board somewere. The math is pritty simple, its like a imaginary collision check.
2.) If there is not enough space then dont charge the bot anything. Make it return that there is not enough space to some memory location so the bot wont be confused if he is a blind dum$$ , but if he is a dum$$ then he probebly wont find that return value eather.
-
X = bots(z).X - Cos((bots(z).ang - 120) / (180 / 3.14159265358979)) * 34
Y = bots(z).Y - Sin((bots(z).ang - 120) / (180 / 3.14159265358979)) * 34
If collision(X, Y) Then
Private Function collision(X As Single, Y As Single) As Boolean
collision = True
For z2 = 0 To UBound(bots)
If Round(((bots(z2).X - X) ^ 2 + (bots(z2).Y - Y) ^ 2) ^ 0.5, 4) < 34 Then
collision = False
Exit For
End If
Next
End Function
-
No No , Py your bug is mood, look here.
Call my bug a mood would you? That's fighting talk that is!
I don't care if you call my bug a quare or even a scroovy quare that things all time but a mood?
If you don't immediately apologize to my bug I will just have to set Hunter 3.3 on you. :D
-
1.) Before repoduction calculate if there is enough range to place a baby. Already works like that in PusherBots source code is attached to the board somewere. The math is pritty simple, its like a imaginary collision check.
Been there. Tried that. No it isn't!
2.) If there is not enough space then dont charge the bot anything. Make it return that there is not enough space to some memory location so the bot wont be confused if he is a blind dum$$ , but if he is a dum$$ then he probebly wont find that return value eather.
Agreed but it isn't that easy.
X = bots(z).X - Cos((bots(z).ang - 120) / (180 / 3.14159265358979)) * 34
Y = bots(z).Y - Sin((bots(z).ang - 120) / (180 / 3.14159265358979)) * 34
If collision(X, Y) Then
Private Function collision(X As Single, Y As Single) As Boolean
collision = True
For z2 = 0 To UBound(bots)
If Round(((bots(z2).X - X) ^ 2 + (bots(z2).Y - Y) ^ 2) ^ 0.5, 4) < 34 Then
collision = False
Exit For
End If
Next
End FunctionThis measures a single point for a collision with other bots. How is this going to tell me that the whole circle of space that I need is completely devoid of bot parts?
Yes it can be done but why bother. It is a pointless waste of programming time and just adds yet another complex and slow procedure to DarwinBots. We are trying to pare it down not make it bigger and more cumbersome.
Much better to just charge for the existing DNA on each cycle. I prefer to just charge for active genes but I don't mind if we add a system for charging for base pairs like Num suggests.
IMO the fact that a robot gives away a huge chunk of its own energy when it reproduces anyway, is plenty to charge it.
-
ic
-
When a robot has no space to reproduce but tries to anyway, repro will fail but he will still be charged energy for the attempt. This is stupid, unrealistic and sucks a lot!
I think this problem shall go away when (if?) Nums adds that realistic size/energy for bots. Bots would DIVIDE, not CREATE another entity.... That shall be so sweet... :drool:
-
I dont deserve so mutch stars! who cares about entitys ?... :P
-
I think this problem shall go away when (if?) Nums adds that realistic size/energy for bots. Bots would DIVIDE, not CREATE another entity.... That shall be so sweet...
I don't think this will be so hard to do really.
We just create 2 smaller bots in the space originally taken up by one. Possibly start them in the same position and just allow the game physics to move them apart.
-
I dont deserve so mutch stars! who cares about entitys ?... :P
Are you actually from this planet?
Sometimes I wonder.
-
I see what your planning now, indeed it is a good solution.
-
I don't think this will be so hard to do really.
We just create 2 smaller bots in the space originally taken up by one. Possibly start them in the same position and just allow the game physics to move them apart.
But remember that size will now be (in the newer versions) directly related to volume, which is directly related to body currently. So it may not be quite that simple.
-
So are you planning on having the robot slowly stretch out into two while maintaining the same volume inside the cell membrane. Now that would be cool. B)
-
So are you planning on having the robot slowly stretch out into two while maintaining the same volume inside the cell membrane. Now that would be cool. B)
That would be cool, I just have absolutely no idea how to do it. It would make collision detection infinitely more difficult. There are alot of optimizations made when we know bots are spherical (or nearly so).
I'm open to suggestions.
-
Well I was thinking of creating a new bot on top of the old one with both the same size (kind of like splitting the cell nucleus) then change their sizes as they move apart until they fully separate. It should be fairly easy to come up with a formula that defines their volume change as a function of how much the two circles overlap.
Then we can change the width of the connecting tie to exactly match the diameter of the robots
Another cool thought I just had was to change the width of ties so that short ones are fat while stretched out ones get thinner. ie. keep the volume of a tie constant.
-
Well I was thinking of creating a new bot on top of the old one with both the same size (kind of like splitting the cell nucleus) then change their sizes as they move apart until they fully separate. It should be fairly easy to come up with a formula that defines their volume change as a function of how much the two circles overlap.
Then we can change the width of the connecting tie to exactly match the diameter of the robots
Only problem is of course the sudden potential energy change.
That is, two bots overlapping all of the sudden can cause a case of energy from nowhere. Like one electron suddenly creating another, both overlapping, both with a great deal of (perhaps nearly infiinite) potential energy.
Another cool thought I just had was to change the width of ties so that short ones are fat while stretched out ones get thinner. ie. keep the volume of a tie constant.
Sounds like a good idea to me.
-
Only problem is of course the sudden potential energy change.
That is, two bots overlapping all of the sudden can cause a case of energy from nowhere. Like one electron suddenly creating another, both overlapping, both with a great deal of (perhaps nearly infiinite) potential energy.
That shouldn't happen with the physics that I set up a few releases back. There is no longer any repulsion field so no accelerations are ever applied to overlapping bots.
All it should do is physically displace both bots away from the combined centre at a rate of half of the physical overlap per cycle. No accelerations! just a gentle push that decreases displacement as overlap decreases.
You haven't changed the physics have you?
If not then I repeat, just calculate the amount of overlap and from this work out the combined volume. Then just apply a corrected diameter to each bot as they slowly separate. It should take about 10 cycles for them to part ways. Just give them a very small offset of a couple of twips to set them on their way.
-
You haven't changed the physics have you?
Um... :redface: I changed them to use forces. Bots now act like damped springs. And so do the edges of a non toroidal world, and just about anything else you can imagine. It works about the same actually.
Perhaps a parent cell engorges itself until it's diameter is the same as the two daughter cells, and then it pops into the new two cells?
-
You see , they talk to each other , and they like each others ideas.
I wish ... ]
Delete..........................................
-
Better go piss the badgesedts out of sony online entertainment.
-
You see , they talk to each other , and they like each others ideas.
I wish ... ]
That is only because we are talking about stuff that makes sense to do and will ultimately improve the DarwinBots experience.
When you start making sense we will start listening to what you have to say.
-
I just wanna tell you that this poll have multiple option vote
-
Hey Zelos! Where have you been for the last couple of months?
-
yea:
-
ive been in the land of waiting and waited for the enzymes
-
If you were to increase the chances of deletion of information wouldn't that also help keep junk dna limited or would it stifle evolution too much?
-
It would help in a bot with a lot of junk DNA but hinder a streamlined bot with mostly useful DNA, I'd have thought. It would depend on the bots in the sim.