Non-Determinstic Bot DNA flow

[Numsgil]

Dijkstra, that crazy guy.  It's scientists like him that give the whole field a bad name!  I mean, how can anyone take you seriously when you start talking about philosophers eating spaghetti?  Is it any wonder I switched to from Computer Science to Mathematics?  At least ring theory makes sense, and sounds cool and scientific :P

The system you propose does have some strengths, but let me balance you pro list with a con list:

1.  Effective speeds of the already fairly slow program will be lowered.  This is a simple consequence of only being able to execute part of your genome at a time, which makes the slice of time a cycle represents lower.  The longer your genome, the less each gene gets per cycle, so the slower the bot will appear to react (unless you load up genes with a bunch of unrealted instructions, that is, make all bots short bots).

2.  You've created race conditions.  Which is probably bad.  The current system is reliant on the timing of the genes, but it is so in a predictable way, so it doesn't count as a race condition.

3.  Genes have clear incentive to multiply in the genome.  This can lead to explosive copying of genes and elimination of competitors (delgene everything but yourself).  This is not inherintly a bad thing, but the emphasis of the program should be on the behavior of bots more than the competition of genes, and a cancerous runaway gene copying itself could slow the simulation and use up quite a bit of memory.

I've voted against several ideas on the basis of gene competition alone.  Keep competition between genes limited.  (If you can't see why, I can elaborate further, but my reasons are half forgotten, so I'd have to sit down and reremember it).

4.  Bots with one gene work just as well in the current system as in an ND system.  Inherantly, you're thinking of genes as one or two command segments, roughly of equal length between all bots.  But some modern genes can be monsters.  In your example, a gene that does what both genes does is better than the two smaller versions put together.

So in the end you're encouraging bots to either have 50 copies of the same gene or a single gene that does it all.  Again, this is not inherintly bad, but I would prefer to see large segments of passive and different DNA develop over large segments of active duplicate DNA.  Both are likely to develop something, but if the DNA is encouraged to spread out it makes it more readable and reverse-engineerable.

5.  And also there shouldn't be an inordinately huge difference in execution speeds between a single gene bot and a multigene bot, since genes are all supposed to be executing simoltaneosly.  In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot) while another bot only gets to execute part of his, which implies the genes are running at different clock speeds, which is a fallacy.

That is, you're trying to balance the field by saying each bot gets to execute one gene per cycle, when it should be that each gene gets to execute as often as all other genes, (including genes in other bots).  A simple fix is to have a counter for genes that prevent them from activating until after X cycles.

I think you're moving in the direction of sims like Avida, which give organisms a time slice to execute in.  For your system to work, all bots must have a finite time slot in which to execute which is roughly equal to all other bots.  That is, all 50 of bot A's genes should appear to have executed in the same time period that bot B's one gene did.  (Again, all genes happening at the same moment).

This is really the strength of DB.  The program isn't making artificial distinctions within the DNA, but the bots end result is what's tested.  This is what attracted me to the program.  It's so different from all otehr ALife sims that it's found a niche.  There's no reason to follow the rest of the crowd when we're doing just fine in our current system.

6.  Most of the benefits of your system can be achieved in other ways.  For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).  Backwards compatibility is important to maintain when possible.  There isn't anything your system can do that we can't adapt the current language to do just as well with a little imagination and time.

[PurpleYouko]

Maybe the definitions have gotten mixed up.
There may well be more than one defininition of non-determinism in computer science but then that isn't my field so when we start talking about determinism , I see it in terms of physics and chemistry. (my fields)

Determinism at a quantum level is absolute with respect to wave forms and probabilities but it is inherantly impossible to precict the position, and velocity of a single particle so any direct effect that this particle has on any other particle becomes non-deterministic in an absolute sense.

On a macroscopic level, the only thing preventing us from being able to determine the way one single atom of air in one part of the world, effects another single atom in another part of the world, is a lack of information about the all of the physical position, velocity, temperature etc. of all the others in between. If we had the ability to know all of this and the computing power to model it then we would be able to determine the exact effects.

With enough information, we could model all macro-molecule interactions (including DNA/RNA) and see that they become completely predictable based on causality.

The different genes should be found to work in parallel with small strings working in sequence. A particular part of a gene will produce a specific protein based on a specific input. Then that protein can be used for some other action within the sequence.

Sounds like Num's proposed idea and I like it.

I don't see any realism whatsoever in the Daemon system. In a real organism, any gene activates whenever it gets the right input. You can't just arbitrarily stop a chemical reaction! When the right chemicals come together in the right proportions and orientations, THEY WILL REACT
It isn't what I would call elegant. It is closer to what I would call a complete misrepresentation of reality.

Sorry and all that but I hate everything about it.

[Carlo]

1.  Effective speeds of the already fairly slow program will be lowered. 

This is true. But, as I already told you, I'd prefer a good program that works slowly than a bad program that works faster.

2.  You've created race conditions. 

Can you be more specific about this point?

3.  Genes have clear incentive to multiply in the genome. 

No. A gene can reproduce itself only making the bot work successfully and reproduce. There's no reason for a gene to duplicate against the advantage of the bot it is in. A gene must be cooperative towards the entire genome (this is the concept of gene pool). Even in the case of a gene able to actively duplicate itself inside the dna of a robot (in case there will be commands for doing so) duplicating too much will subtract energy and _time_ and lead to a rapid death of the whole organism. So, NOW genes have a clear incentive to multiply themselves in the genome, since time is not a resource. Think of viruses: they rapidly spread in the whole population, and can infect a bot with as many copies of themselves as they want.

I've voted against several ideas on the basis of gene competition alone.  Keep competition between genes limited. 

Again, genes in general won't compete, as their interest is the robot's interest.

4.  Bots with one gene work just as well in the current system as in an ND system. 

Yes, this is a problem. I haven't tried it, but I know there's a very strong robot having only one gene. For it there would be no difference between deterministic and nondeterministic execution. There would be two possibilities here: either accept this fact (bots like the One will never evolve in an evo sim, so there's simply no problem) or put a limit to the number of operations that can be performed inside a gene. The limit may be a simple cap or maybe an increasing cost for each subsequent operation.

So in the end you're encouraging bots to either have 50 copies of the same gene or a single gene that does it all.  Again, this is not inherintly bad, but I would prefer to see large segments of passive and different DNA develop over large segments of active duplicate DNA.  Both are likely to develop something, but if the DNA is encouraged to spread out it makes it more readable and reverse-engineerable.

I'm not sure to understand what you mean. Remember that active copies of the same gene are also subject to mutation. This means that duplicated genes are a good material for evolution. Also, remember that an inactive gene, lacking of any selective pressure, becomes in a few generations a complete junk, and going back from junk to a functional gene is extremely improbable.

In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot)

This, again, depends on decisions we may take to discourage too complex genes. But, also, it is a problem which can affect only people programming combat bots, since I don't think that evolution will produce super complex genes.

when it should be that each gene gets to execute as often as all other genes, (including genes in other bots).

Hmmmm... from a certain point of view you're right. This is how things work in the real world. But on the other hand, we should design the program to produce interesting and meaningful results. And making behaviours compete for execution time could be interesting. In Avida, one of the most "serious" alife software, organisms compete for cpu time. The real world works differently, but this choice is interesting, and profound. By contrast, the meaningless energy parameter in DB is really a stupid idea.

This is really the strength of DB.  The program isn't making artificial distinctions within the DNA, but the bots end result is what's tested.  This is what attracted me to the program.  It's so different from all otehr ALife sims that it's found a niche.

DB isn't different from other alife sims. It's just what a true alife sim should be. Now, changing the way dnas are executed to a more coherent and elegant system, which, among other things, introduces time as a resource (think carefully about this: the only significant resource in a world in which matter and energy don't exist, it's time) don't seems to me to change the fundamental properties of fairness and open endedness of the simulation.

There's no reason to follow the rest of the crowd when we're doing just fine in our current system.

It's not a matter of crowds or niches, but of what is and what isn't interesting, elegant, coherent.

For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).

Horrible. :lol:

Backwards compatibility is important to maintain when possible.  There isn't anything your system can do that we can't adapt the current language to do just as well with a little imagination and time.

Backwards compatibility is a stupid thing if referred to a program that nobody uses for work but just to tinker a bit with evolution and robot programming - don't you think so? I find this idea simply intolerable. You know what's better, how the program can become more interesting and be a better alife sim... but you do nothing, because of the back compatibility of a few bots... bah.


Anyway, seems to me we're blocked. You'd never accept the nd solution. I've thought of a compromise. It should work this way.

All active genes are executed. The values are read from the memory array, but the store command writes to a list of lists. For example: the operations:

1 10 store
2 20 store
2 20 store
5 50 store
6 50 store
7 50 store


will produce the list

10 ->1
20 ->2,2
50 ->5,6,7

At the end of the complete cycle, the memory array is written with values taken from the list. If a location has more than one value associated, the value to write in the memory array is chosen randomly among the values in the list.

This way, we'll have some of the good effects of nondeterminacy (duplicated genes still active, memory and external effects visible at the same time, genes balancing) but executing all active genes at each cycle. The time effect, which I think would have been interesting, won't be present. To prevent communication between genes in the same cycle I'd also reset stack pointer after each gene.

Comments?

[shvarz]

I also agree that we are stuck, I see good points from both sides and only time can tell who's right.  So I'm OK with the compromise.  It actually does sound a bit like Nums' chromosome idea (which I am not too fond of either btw).

But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location?  That way it can be done on the fly.  My personal preference would be to allow 100% chance of writing something in a memory location if the current value there is 0.

Also, we can introduce some kind of commands that would define the "efficiency" of a gene.  Say some mutatable number located immediately before condition - express it as a percent of 32000 and let it represent the probability of over-writing any values by the gene that follows.

[Carlo]

But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location?

This way, genes with the most chances of having effect would be genes at the end of a dna. If I have four instructions:

1 10 store
2 10 store
3 10 store
4 10 store

4 has 50% probability to be written in 10; 3 has only 25% chances to be written, 1 and two have both 12.5 chances of being written.

Anyway, the idea of always overwriting zeros is unfair (for example, in a counter or a flag 0 and 1 have an equivalent importance); so you'd need anyway a list.

Also, we can introduce some kind of commands that would define the "efficiency" of a gene.  Say some mutatable number located immediately before condition

It seems to me that just duplicating genes would be enough...

[Numsgil]

I can accept anything if you're talking about it from the point of view of an option.  THe more the merrier.  I would definately like to explore an ND DNA execution model, just not for the main course of the program.  It's main interest is in evolution sims.

I'll write up another post on how I would improve the ND system you imagined.
Your compromise works exactly like how I invisioned chromomes to work initially, so it's obvious that it's a good solution if more than one person have arrived at it more or less independantly.  I certainly support it as the main direction for DB to follow.

Shvarz's two ideas:

1.  50% chance on overwriting existing value: this still creates linearity between genes, with genes comming after other genes more likely to overwrite the one before, which is a problem.

2.  Having each gene have a number strength was proposed by Zelos too a while ago for how to figure out dominant/recessive gene pairs.  As I said to him, it just creates incentive for a gene to mutate its strength to 32000.  There's no downward force on gene strength (unless it's just a bad gene.  But then we don't care much about it anyway).  Stength or lack there of of a gene or command should be determined intrinsically by the system.  Real genes aren't recessive because the genome designed them that way.  It's just how it worked out.
For Carlo's idea: having which number to store in case of conflict be random works well enough, but I'm leaning more towards a higher probability for some kinds of instructions over others so recessive/dominance can be established.  If you imagine a diploid animal with two identical chromosome pairs except one fires -6 shots and the other -1 shots, picking a random instruction to use results in each being 50/50.

If you have some rule that creates preference for certain kinds of values (I'd probably vote for values closest to 0), then you can create a dominant/recessive pair, and hopefully allow some classic sexual reproduction to be worked into the system.

So the chance of being chosen from the list of conflicting commands should be partly random (favors more frequent commands) and also partly biased (favors certain kinds of commands over others).

A simple slider between the two can allow us to tweak and decide which is best.

[Numsgil]

As promised, this is my thoughts on how to improve the ND system.

This is true. But, as I already told you, I'd prefer a good program that works slowly than a bad program that works faster.

Definately.  But DB isn't a bad program.  At worst it's an ameteurish program.  And a large part of what makes it that way isn't the DNA system or mutations, it's the physical speed of the simulation.  Avida lets you run whole generations more or less within an hour.  DB runs almost at real life clock rates.  Sloooow.  If I can find ways to bump up its speed, especially on larger simulations, by maybe a factor of 10, the program suddenly becomes competitive to others.

2.  You've created race conditions. 

Can you be more specific about this point?

In concurrent programming, racing conditions is when the order of two or more supposedly concurrent actions effects the end action taken by the system.  I don't understand it well enough to give you a huge overview, but this is how I understand it:

Suppose two genes both work when nrg 5000 >:

cond
*.nrg 5000 >
start
50 .repro store
stop

cond
*.nrg 5000 >
start
100 .up store
stop

Now, in regular DB both are executed every time.  If this is the entire genome, the actions of the cell are quite predictable and consistant.

In ND, one executes then changes the conditions, then another executes.  Any of these is possible:

reproduce only
move then reproduce
move several times then reproduce

Which is chosen has absolutely no correlation with anything.  By definition, you've made it random.  This is called a racing condition, and is generaly agreed to be a flaw in the system.  Wether it is in DB or not I have no idea, which is why I said it's probably bad.

I don't know enough about the consequences of racing conditions to know one way or another.

(bots like the One will never evolve in an evo sim, so there's simply no problem)

...

But, also, it is a problem which can affect only people programming combat bots, since I don't think that evolution will produce super complex genes.

They don't in the current system because there's no incentive to do so.  Two genes work just as well as one big gene.  Over time, simple diffusion will result in a genome that's more spread out into multiple genes.

In a ND system, it's not at all impossible that such a bot would develop.  There's certainly nothing stopping it, and incentive to do so.  Dropping one gene from a 50 gene bot is hardly noticable, but dropping one gene from a 2 gene bot gives the other double the execution time.

put a limit to the number of operations that can be performed inside a gene. The limit may be a simple cap or maybe an increasing cost for each subsequent operation.

A cap is always a bad option.  Sometimes unavoidable, but usually a bad bad idea.  The second option is better.  You need to create a counter incentive to the one gene geonome.  Increased costs works well enough, I'm sure there are other ways as well.  You could increase waste generated.  Anything really.

Hmmmm... from a certain point of view you're right. This is how things work in the real world. But on the other hand, we should design the program to produce interesting and meaningful results.

There's nothing that a ND system can produce that the calssic system can't.  There aren't any new commands, or new ways to mutate the genome.  The effects of mutations are a little different, creating different paths for the genome to take, but the end results on the behavior of a bot are more or less the same.

A well designed ND bot does just as well in a ND universe as a well designed classic bot in a classic universe.

And making behaviours compete for execution time could be interesting. In Avida, one of the most "serious" alife software, organisms compete for cpu time. The real world works differently, but this choice is interesting, and profound.

Which is why Avida uses it as its paradigm.  There's nothing wrong with it at all, but Avida already does it, and does it better.  To the best of my knowledge, no one has tried modelling real life as well as DB has.  I think, when possible, we should construct the bots to operate as closely as possible to real organisms.  It makes it more interesting both to laymen and hobbyists.  We don't really have any proffessional researchers using DB, but I imagine they wouldn't care one way or another.

For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).

Horrible. :lol:

What is horrible?  The idea of a sleep command or...?

Backwards compatibility is a stupid thing if referred to a program that nobody uses for work but just to tinker a bit with evolution and robot programming - don't you think so?  I find this idea simply intolerable. You know what's better, how the program can become more interesting and be a better alife sim... but you do nothing, because of the back compatibility of a few bots... bah.

When people spend hours working on something, they don't like that time to be wasted, no matter wether it was for fun or work.  That doesn't mean you are limited to backwards compatibility, just that you should strive for it and only abandon it when the benefits of a new system far outweight the combined grief of the people.

For instance, if a new version of Unreal Tournament comes out that uses a special foot controller, and hand mice aren't allowed anymore, the new foot controller better be way better than the old hand mice system.  I've spent alot of time practicing and honing my skills with the hand mouse.  That time's wasted if the new foot controller is no better than the hand mouse.

We even considered breaking current bots when we were thinking about an enzyme system, but with a little thought we managed to modify the idea to where existing bots would work just fine (provided default enzymes by the program).  Usually not making something backwards compatible is a sign you haven't tried.  And I don't think you've really tried.
Okay, here's my comments on the ND system.  If you work these out, I think it would be an awesome option (but an option it must remain!)

Real ND languages (the kind you're actually talking about, not the tree kind) only execute one body over another if both conditions evaluate to true.  It doesn't try executing a body if its condition isn't true.

So I would scan the genome for all genes that evalutate to true, and then chose one among them to execute.  That keeps the basic ND flavor (actually increases it!) while enhancing its capability.

There was something else but it escapes me at the moment.
Last, the original ND idea I'd like to call the 'hard ND' system, and continue discussing its possibilities here.

The compromise system, which is so similar to the chromosome system that they're really the same idea just with some fine differences, I'd call 'soft ND' DNA execution, and really should be discussed in a new thread, perhaps, so we can continue working on the hard ND system in this thread.

[Carlo]

I would definately like to explore an ND DNA execution model, just not for the main course of the program.  It's main interest is in evolution sims.

But evolution sims ARE the main interest of the program. Any other use is secondary.

A simple slider between the two can allow us to tweak and decide which is best.

The idea of deciding an explicit -and totally arbitrary- method to favour recessive genes seems to me simplistic. Remember that robot in DB are still simply virtual machines storing _values_ in a memory array, NOT bacteria producing this or that _amount_ of proteins or enzymes. Pretending that a value stands for an amount (hmmm ... and what about shoot's -1 and -2? shootval locations? tie messaging? ) is wrong. It adds new intricacies to the way dna works. Things have to be SIMPLE. Clear. You've managed building a program that's every day more and more complex, with more rules, each with its own exceptions. Probably the only way to program a good bot today is to study the source code of the program to have an exhaustive idea of all its intricacies.
And now you want to add a SIMPLE SLIDER which decides how the dna should be interpreted? So that a gene is recessive, provided that the slider is in the correct position? Yeah, let's make it. We'll call it the stupidity slider, and it will have two labels at the two ends: "more" and "less".

[Numsgil]

But evolution sims ARE the main interest of the program. Any other use is secondary.

You may have designed it that way, but the current system is very much a dual interest.  Evo sims are not either better supproted or more interesting than designing bots.  This is a huge benefit of the program.  Alot of the new people we get are first and foremost interested in designing bots.

The current system works just as well for either, while the ND system is only really interesting to evo sims.  That is what I meant.

Yeah, let's make it. We'll call it the stupidity slider, and it will have two labels at the two ends: "more" and "less".

Okay, first insulting your only supporter (albeit a mild one) is definately "more".

Second, the slider all the way to one side would be the same as just randomly picking one, which is what you're proposing anyway.  (I assume you're calling your own idea "less stupid"?  Probably not the term I'd use to describe an idea of my own)  Seriously, what's the problem with giving the user more choices?  The only possible problem is making the program look more intimidating to new users.  There's ways to fix that (embedded options controls that are hidden from the user).

The idea of deciding an explicit -and totally arbitrary- method to favour recessive genes seems to me simplistic. Remember that robot in DB are still simply virtual machines storing _values_ in a memory array, NOT bacteria producing this or that _amount_ of proteins or enzymes. Pretending that a value stands for an amount (hmmm ... and what about shoot's -1 and -2? shootval locations? tie messaging? ) is wrong.

You're right, it is arbitrary.  But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.

So what if -1 shots are dominant and -6 shots recessive?  6 fingers is a dominant gene, but it's worse than 5 fingers.  (The 6th finger is useless).  Dominance and recession is just useful for heterozygousy, which is important in dipolid organisms engaging in sexual reproduction.  Having -1 shots being dominant won't mean -6 shots can't develop.  It just means when they do they'll be homozygous.

You've managed building a program that's every day more and more complex, with more rules, each with its own exceptions. Probably the only way to program a good bot today is to study the source code of the program to have an exhaustive idea of all its intricacies.

Yes, this is my goal.  Complexity.  I've said it before and I'll say it again.  When I'm done, it'll be impossible for any one person to understand everything in DB!  Why?  What possible masochistic reason would I have for such a thing?

Complex systems, what ALife is all about.

Emergence - more is different

What distinguishes a complex system from a merely complicated one is that some behaviors and patterns emerge in complex systems as a result of the patterns of relationship between the elements. Emergence is perhaps the key property of complex systems and a lot of work is being done to try to understand more about its nature and the conditions which will help it to occur.

The behavior of a complex sytem can not be understood in terms of a simple extrapolation of the properties of its components, elements and entities. As P.W. Anderson said in his 1972 science article (Science Vol. 177 No. 4047), more is different. At the macroscopic level of the system, new properties appear which can not be predicted by the properties of microscopic components.

Typically, the relationships between elements in a complex system are both short-range and long-range. The direct local interactions are short-range, that is information is normally received from near neighbours. Through top-down feedback and small-world connections agents can indirect influence all other agents. The richness of the connections means that communications will pass across the system but will probably be modified on the way.

Don't you see?  Simplicity is death.  The sure and simple path leads only to stagnation.  That's where many ALife programs fail.  In a simple system organisms can adapt quickly, but there's nothing new or unexpected.  It's just a solution to a problem.  It's stagnant and pointless.  Who cares that the things can figure out the right value for 3 sliders?

But complexity.  Now there's real interest!  Yes, I will keep making the proram more complex.  Each and every day!  People will cry out in pain that they can't understand how all the parts are working together but the bots know.  They know!

Hahaha!

When I added *.thisgene, I only invisioned it for *.thisgene .mkvirus store.  But people found new and interesting uses for it in conspec ID, antivirus genes, etc.  Each and every new element makes the program so much more than the sum of its parts.  The only problem is in balancing them, and what better way than a slider the user can play with?

[PurpleYouko]

Yes, this is my goal. Complexity. I've said it before and I'll say it again. When I'm done, it'll be impossible for any one person to understand everything in DB! Why? What possible masochistic reason would I have for such a thing?

In this I am 100% on the side of complexity. It has always been my beleif that DB is WAY to simplistic and I have always argued for adding more complexity to the system.

Where my aim differs a little is in making a lot of the complexity behind the scenes while attempting to make the robot DNA commands somewhat easier to use (not to understand).
I may be primarily a genetic engineer as far as DB goes but I do want to see the evolution side of the game thrive too. For that to work, we could really use some simplified DNA commands. That is why I introduced the recent tie controls and plan on working to find ways to simplify the rest of them to the point where evolutionary adaptations might actually be able to use them.

I think the idea of diploid DNA with recessive/dominant genes is great. If we can't use some sort of user control such as sliders to determine which is which then we are stuck with a choice based solely on the decision of the programmer.
We can't realistically make it just random so we have to have rules.
What better way than to allow the user to define his own rules?

[Carlo]

The current system works just as well for either, while the ND system is only really interesting to evo sims.  That is what I meant.

How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"? Are you saying that it would actually work better than the actual, but you don't want to switch because it would be (thing which I don't really believe) a problem for combat sims?

Okay, first insulting your only supporter (albeit a mild one) is definately "more".

Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.

Seriously, what's the problem with giving the user more choices?

Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.

But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.

I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.

Yes, this is my goal.  Complexity.  I've said it before and I'll say it again.  When I'm done, it'll be impossible for any one person to understand everything in DB!  Why?  What possible masochistic reason would I have for such a thing?

This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways. Think of Conway's game of life, for instance. How much time will take you to explain the rules of the Conway's universe to a newbie? 1 minute? And cellular automata generate complexity. A predictable complexity, where emergent properties are possible. On the other hand, many rules, some ad hoc, patching other rules here and there, designed to provide only a precise outcome, produce only chaos. How much time would take you to explain how DB works to a newcomer?
The text you quoted defines perfectly what DB is becoming: complicated. Not complex.

Who cares that the things can figure out the right value for 3 sliders?

I absolutely agree with you on this point. Most alife sw out there perform just some kind of optimization, not evolution.

When I added *.thisgene, I only invisioned it for *.thisgene .mkvirus store.  But people found new and interesting uses for it in conspec ID, antivirus genes, etc.

That was a good idea. Others (actually _many_ others) aren't. For example, mkvirus isn't a good idea. You had the opportunity of designing a whole new system for copying genomes and reproducing (an activity which should require a complex activity, and _time_), and just as a side effect create viruses, as well as all the other effect you just mentioned. Mkvirus, by contrast, is really a little, ad hoc idea.

The only problem is in balancing them, and what better way than a slider the user can play with?

Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.

[Numsgil]

How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"?

What I mean is that currently, I have just as much fun writing bots as running evo sims.  I can run evo sims in any program, but DB allows me to really put my programming skills to the test and make some killer robots.

The ND system is more interesting from an evo sim standpoint.  Writing bots in it becomes more difficult because you can't be sure how it's going to act.  If you see it not do X, you don't know if it's not doing it because the DNA isn't working or just dumb luck.  You quickly become frustrated and give up.

I don't think either system is better or worse for evo sims.  Bots will adapt given enough time to any settings.  As long as they can survive at all.  I don't think ND adds anything to evolution that can't be added in other, more backward compatible ways.

Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.

Perhaps it's losing what made it interesting to you, but it becomes ever more interesting to me as time goes on.  Do you realize that this is the longest I've ever worked on a single project?  6 months.  That's incredible for me.  So it must hold some allure to me.

I'm sure most other people would agree with me on this.  There hasn't been a stable release yet that I find less appealing than the version before.  The moment (multiple I suppose) people pine for an older version is the moment we know we've moved in the wrong direction.

At some point you have to accept that you're idea is either wrong or unpopular, which amounts to the same thing in a collaborative effort.  Not every idea I've had has been good or popular, and it's only been through half a dozen people telling me so that I've come to realize when this is the case.

The only idea I've refused to give up on is chromosomes and sexual reproduction.  For months now I've hammered away at the problem.  If you check some old threads, you'll see how my idea has matured as people have continually said "no, and here's why".

Take the criticisms of your idea and fix them.  Re examine the original goals and see where a different system can work.  As programmers we understand that there's no such thing as a perfect solution.  Hammer away again and again at the problem until a solution is found.

What you see as elegant I see as different.  While it solves many problems, it creates many new ones.  If you can find ways to fix the ultimate unfairness (each gene in the simulation needs to execute as often as all other genes), the idea would then be 'elegant'.  Add to that backwards compatibility, and the idea would be brilliant.  It would make me cry tears of joy.

Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.

This particular slider doesn't dictate how the DNA is executed, but the magnitude of a particular effect.  It would be one thing if the slider was between reverse polish notation and Polish notation.  Then it really would be stupid.  This slider is more for the discrepancy between recessive and dominant genes, which is something that the user has every right to play with.  I can imagine many interesting experiments that can be performed using different settings.

Might even be a worthwhile paper.  The Effects of Gene Dominance on Adaptive Systems.  Might be there's no difference.  Might be it makes adaption harder.  Might be it makes it easier.  I don't know anyone's really played around with it to find out.

I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.

Speaking of ideas no one likes...  This one I've been pushing since before we moved boards.  No one likes any idea I can come up with for establishing dominance or recession.  I've tried hash functions, arbitrary rules, just about anything I can think of.  Notice I keep trying new ideas.  Eventually someone will like one of my ideas, or I'll think of something else that allows this as a natural consequence (the golden idea).  You just have to keep plunking away until something works that people like.

This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways.

True, but the simpler the rule set, the less complex it is.  The real world has so many interconnected rules operating on each other.  Most of them don't appear to be related at all (Unified Field Theory aside).  Imagine if DB had people who dedicated themselves to combat techniques, or multibot creation, or chasing behavior.  When you can get all of DB in your head at once it's too simple.  This isn't a game, you don't have to understand all the rules to play.

As PY said, as long as the interface is relatively simple, as long as new systems follow the interfacing patterns of older systems, each and every new element makes the program ever more complex, adds newer and newer shades of grey to a still rather black and white program.

I agree that many systems in DB are adhoc.  Viruses are quite an arbitrary add-on.  But the core of Darwinbots is very simple, and has remained so.  While it would take several hours to explain all of DB to a newbie, it would take only a few minutes to explain everything necessary to either create a bot or run an evo sim.

As long as that base, the absolute minimum, remains fairly clean, even ad hoc addons fit well into the mesh.

If I had designed viruses, likely I would have coupled it with a sexual reproduction system, and gene transferance like between bacteria.  But each programmer has a different way of solving a problem, and especially in a free projet like this, time is a factor.  I'm pleased enough with viruses as they stand.  There's more that can be done in this area, but it's not a bad system at all, and it's simple enough to get working (.mkvirus, .vshoot, .vtimer)

I also agree that reproducing should take more time, but I'm not sure how well such a suggestion would be recieved, so I hold my tongue.  It's a minor point that I don't feel is hurting either evolution or leagues, but does upset subtle implications within the program.  Much better to concentrate on specific criticisms of the program that are widely held.  The big problems that need to be tackled:

1.  Speciation isn't possible
2.  It's hard to create a predator/prey cycle without veggy population limits or repopulating veggies, both of which are very artificial.
3.  Sexual Reproduction isn't possible and/or doesn't work (what we have, no, isn't really sexual reproduction, but a kind of bastard child of sexual and asexual reproduction).
4.  The program takes too long to evolve bots for the impatient (simulation speed)
5.  And, if you believe what Botsareus keeps going on and on and on and on about, "mutations don't work!!!!1111".

These four (5)  problems are where I spend most of my time.  Everything else is candy.

Notice when I first tried tackling the removal of the linearity between genes, it was done with the intent of allowing diploid organisms to develop and sexually reproduce with real life rules.  Ie: problem 3.

Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.

On some points yes, but constants should always be user defined, except where they're important for speed optimizations (maxspeed makes collision detection bearable).

What the program does can be arbitrary, but to what extent it does whatever it does needs to be user defined.  And, of course, good defaults help users make sense of it all.

[Carlo]

Writing bots in it becomes more difficult because you can't be sure how it's going to act.  If you see it not do X, you don't know if it's not doing it because the DNA isn't working or just dumb luck.  You quickly become frustrated and give up.

That's your pure supposition, you haven't even tried. If a gene has 1/3 chances of being executed at each cycle, if your sim runs at 30 cycles/second it will be executed 10 times on average each second. This seems to me enough to exclude "dumb luck", from the point of view of the programmer.
Programming ND bots would be a new challenge for the programmer, asking him to take in account also the time/ chances effect, on one end, and the complexity, on the other.
Anyway, I'm not trying to convince you, as this is obviously impossibile...

Do you realize that this is the longest I've ever worked on a single project?  6 months.  That's incredible for me.  So it must hold some allure to me.

Well, this explains a lot of things. If you had been working on it for six years, probably you'd see things in a different way.

At some point you have to accept that you're idea is either wrong or unpopular, which amounts to the same thing in a collaborative effort.

Yes. And that's why I hate people. :lol:  I don't like to remind this to you, but think of the average level of evolution sims around... and you'll understand how much the "popular judgment" is reliable.

True, but the simpler the rule set, the less complex it is.

Balls. Fractals are complex, particle simulations are complex, cellular automata are complex... all examples of complexity generating from a few simple rules. Evolution generates a great amount of complexity, with just two little rules. So, keep in mind that complex systems aren't complicated systems.

Ok. I think this discussion can stop here. I have no more time to devolve to it now (I've lost enough in the last week). Since it is you who are working on the code, you have the final decision. At least, I hope that some idea may have passed (not the ND idea, but the fact that there's something wrong, both from the point of view of coherence, and that of evolution in the way dnas are executed, and the importance of the time factor, and so on).

[Numsgil]

You sure now how to depress a guy.   :lol:

I'll play around with it and add ND as an option.  There's nothing that says the program can't house every imaginable simulation variety at once.   :)

[Griz]

The current system works just as well for either, while the ND system is only really interesting to evo sims.  That is what I meant.

How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"? Are you saying that it would actually work better than the actual, but you don't want to switch because it would be (thing which I don't really believe) a problem for combat sims?

Okay, first insulting your only supporter (albeit a mild one) is definately "more".

Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.

Seriously, what's the problem with giving the user more choices?

Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.

But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.

I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.

Yes, this is my goal.  Complexity.  I've said it before and I'll say it again.  When I'm done, it'll be impossible for any one person to understand everything in DB!  Why?  What possible masochistic reason would I have for such a thing?

This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways. Think of Conway's game of life, for instance. How much time will take you to explain the rules of the Conway's universe to a newbie? 1 minute? And cellular automata generate complexity. A predictable complexity, where emergent properties are possible. On the other hand, many rules, some ad hoc, patching other rules here and there, designed to provide only a precise outcome, produce only chaos. How much time would take you to explain how DB works to a newcomer?
The text you quoted defines perfectly what DB is becoming: complicated. Not complex.

Who cares that the things can figure out the right value for 3 sliders?

I absolutely agree with you on this point. Most alife sw out there perform just some kind of optimization, not evolution.

When I added *.thisgene, I only invisioned it for *.thisgene .mkvirus store.  But people found new and interesting uses for it in conspec ID, antivirus genes, etc.

That was a good idea. Others (actually _many_ others) aren't. For example, mkvirus isn't a good idea. You had the opportunity of designing a whole new system for copying genomes and reproducing (an activity which should require a complex activity, and _time_), and just as a side effect create viruses, as well as all the other effect you just mentioned. Mkvirus, by contrast, is really a little, ad hoc idea.

The only problem is in balancing them, and what better way than a slider the user can play with?

Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.

been spending some time crawling thru the old messages.
got to say ...
Carlos is right on in his take on where DB is headed ...
perhaps it will become a flash physics sim with pretty bots ...
but it's headed for a dead end as far as being an ALIFE sim.
imo.
which doesn't mean anything anyway. ;)
so it goes.