STOP THE DREADED JUNK DNA IN ITS TRACKS

[Botsareus]

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:

[Numsgil]

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.

[Botsareus]

Calculate length of all dna and put costs on replicating it.

Alright Ill be waiting for it...

[Endy]

Maybe increase the time required for replication based on size. This would probably affect the bots more than nrg requirements.

Endy B)

[PurpleYouko]

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.

[Botsareus]

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.

[PurpleYouko]

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.

[Botsareus]

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)

[Botsareus]

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:

[PurpleYouko]

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.

[Numsgil]

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.

[Botsareus]

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.

[Botsareus]

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

[PurpleYouko]

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

[PurpleYouko]

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.

Code: [Select]

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.