Darwinbots Forum
Code center => Suggestions => Topic started by: Ulciscor on October 26, 2005, 08:57:35 AM
-
Well since everyone has been quite zen lately in the discussion about artificial laws and the emergence of complex systems from a simple set of rules, I have been thinking a lot.
In a lecture today I had an idea, which may well be already known or discussed, or indeed already in practice. But what the hey.
Why not first define an environment in terms of substances and physics, and then impose some rules for how these substances interact. This would be the only artificial rule-making and if it were modelled after real-life then wouldn't be artificial at all, simply a simplification of reality.
You could then add bots (composed of environmental substances) and define all their behaviours as manipulations of the environment.
You wouldn't need rules for their behaviour as they would already be defined from the basic interactions of the environment and its components.
This would also allow new behaviours to be introduces without the problem of them being artificially engineered. In fact, if DNA were remade so that actions were based on the manipulation of substances, all possible behaviours the bot could do would be described.
Does this make ANY sense? It does to me but I'm not too good at describing it. :(
Also I'm sorry if this has already been suggested or discussed elsewhere; if that's the case then someone can delete this thread and point me in the direction of the old one.
-
You are actually describing what I have been saying all along.
The complexity needs to be in the way the bots interact with the world, in physical laws and so on.
Such a program would be cool beyond belief but unfortunately, incredibly tricky to set up.
The bots themselves would also need to be very complex to enable them to interact with the world.
-
You are actually describing what I have been saying all along.
Oops! Sorry [PY] maybe I had the same flash on insight as you did. Just after a sizable delay.
Why would it be tricky to set up? Wouldn't you just need rules for physics and entity interactions? The rest would sort itself out.
-
On the face of it yes.
But what rules of physics and chemistry would you plan to use and which ones would you leave out.
During my Chemistry degree I learned hundreds of rules governing specific chemical reactions and what is scarier is that I also learned that there are close to an infinite number of other specific rules that we didn't even cover on the course.
Beyond that, there are probaly hundreds of times more interactions that we don't even know about than there are ones that have been discovered.
Then there is physics. :blink:
Where do we draw the line? We can't possibly do it all.
What we are left with is a stylized and greatly simplified system which we can impose on our world. Not reality but possibly a close approximation. Maybe not. Perhaps it's better not to even attempt to reproduce real world stuff. Take DB shots and ties. They have no real world counterpart.
Anyway, we have our world now so how do we allow our creatures to interact with it. How do they move, eat, see, reproduce? They can never learn to do it on their own because we haven't yet hard programmed the possibilities into our universe.
In order for a collection of chemicals inside a little membrane to be able to self replicate, there has to be a physical mechanism (chunk of program code) to allow it. There has to be something within the creature that instigates it. There has to be something to control the outcome etc. etc. etc.
You see the problem is that for every action that the creatures can possibly ever take, the world has to be set up to deal with it. If it just wants to rotate 90 degrees, we have to have a section of code specifically designed to allow that to happen.
Maybe somebody else can see a way to make a totally rule-less system but I just can't see any way we can do it.
I would love to try it though. :D
-
But the difference from Ulciscor and PY thought is:
I understand perfectly what Ulciscor is saying, while you PY have been vague in describing your ideas (no offense).
And--->
ULCISCOR that is exctractly what I am thinking!!!!!!!!!
Ulciscor's ideas = PY's ideas = Greven's ideas => PERFECT
It seems we all see it the same way, but have explain them differently, and we therefore have misunderstood each other.
Ulciscor, you have the power of the written text, or what ever I should call it! Thank you!
-
greven, ure kinda like hitler, in the meaning of having hybris (is it called that in english?). but from that ure different. greven remember NOTHING IS PERFECT.
-
Where do we draw the line? We can't possibly do it all.
Totally agreed, so we only add what we need. We can do without EM. We can do without gravity. We can do without strong/weak interactions. Why would we need them?
We will have a finite number of substances. Say 10, then we would need 10^10 rules for them if we define a rule for each substance's interactions with others (including itself). But there might be shortcuts for that too, such as grouping them into collections based on a certain property. Daunting but certainly doable.
The creatures would still run from their DNA, but the DNA would be different. The .up command might be translated as firing a gas or liquid from the rear of the bot (hehe), .shoot may be the ejection of a specified substance from the front.
I think if you group actions and interactions together you can vastly reduce the number of rules neccessary.
-
Zelos, You swedish have no kind of humour! So sad! What I mean is perfect is: perfect = good! It good that we actually share same ideas!
-
The creatures would still run from their DNA, but the DNA would be different. The .up command might be translated as firing a gas or liquid from the rear of the bot (hehe), .shoot may be the ejection of a specified substance from the front.
This is still really going down the same route as DB though.
What we have is a "high level" DNA language with word sized commands just like BASIC.
To get true emergence we probably need to break these down still further into "bit" sized controls such that a bunch of bits can cause a certain action to take place. Change the order of the bits and a slightly different action will take place.
This concept will both simplify the DNA and complicate the inteface.
I still can't quite see how to do this effectively but I think I am starting to come up with a few ideas.
-
I understand perfectly what Ulciscor is saying, while you PY have been vague in describing your ideas (no offense).
I'm sorry you see it that way. I thought I was being rather precise about the problems I foresee.
So long as we reach some kind of understanding eventually, that is all that matters.
-
:( I feel bad now.. Sorry [PY] I just never got what you meant. I expect you were describing it as a scientist whereas I was describing it as a complete novice (no offense to anyone!)
[PY] what is was thinking was:
DNA command --> Environmental interaction --> Action
Do you mean that you don't want commands to commute? (Have been doing maths for the last month so I'm going crazy with maths words).
I.e. "x y" doing one thing and "y x" doing another?
-
Not in so many words.
DNA command --> Environmental interaction --> Action
Let's break this down a tad.
DNA command:
In real life this is a code made of base pairs. let's treat each pair as a "bit". Bang 64 of them together to make a full command. Mutate them bitwise. Result = incredibly complex DNA language that few if any people will be able to program.
Environmental Interaction (I would call it Interface):
This is the crux of the issue. Somehow every possible DNA command has to be translatd into an action in the real world. This is where the disagreements seem to appear.
Think of this as a DNA interpretter. Every possible DNA command has to be interpretted into an action. No emergent funtion can possibly get through this interpretter unless it already contains the possiblity.
Imagine it as an English-Swedish interpretter. All existing word of both languages must be included if there is to be meaningful comunication. If The Swedish language evolves a new word that cannot be directly interpretted into English under the existing rules then it will result in a NULL action.
Am I making sense here with these analogies? Let me know if not. I have always had the hardest job comunicating this concept to others. I think Num is about the only other person who really sees this problem as clearly as I do.
-
Maybe I am underestimating this, but I was thinking group commands together when they have common manipulations.
I'm not entirely getting this base pair/bit thing. Can you try and make it clearer? Or possibly word it differently. I'm notoriously dense.
-
Grouping commands together is good but what I am suggesting is an almost infinite variability within a single command that will allow them to almost flow into each other.
Base pairs are the way that real DNA works. A base pair is kind of like a digital system in a way. Only a certain number of possible combinations exist. The complexity is created by having huge strings of base pairs in different orders to make up a single strand of DNA.
In a computer sim we need to translate this into binary math (the bit system) so I am just thinking that a digital DNA strand would be made up of a stream of bits which for sake of argument could be 64 bits in length.(this will fit into a long type variable nicely) This effectively simulates a very simplified DNA strand in which each base pair can only be in one of two states (0 or 1) instead of the number available in real DNA. The combinations possible with 64 bits making up a single command are 9.22E18 (otherwise know as LOTS)
Some kind of interpretter than takes this DNA command and acts on it to do all kinds of stuff is what we need next.
-
Yeah that is a big number, but can't we rule out some commands as impossible? Rule out others as duplicates?
Aren't 64 bits for a command quite a lot?
-
I sense somekind of "now we just discuss it for academic reasons", meaning that people seem to think it would be to hard to make!
In danish we have saying (freely translated):
When the wind is blowing some take cover,
some builds a cover,
yet again a few are building windmills...
-
Well we will be deciding from discussion whether it can be made to work so it's a good thing really!
-
Yes it is. But I would hate if people got discouraged!!!! Just becuase it seem hard to make! Nothing comes for free.
-
Actually Greven, I think this may be really going somewhere.
I don't think it is fully academic for the sake of it.
I am beginning to develop ideas that could potentially revolutionise artificial life sims if it works the way I thnk it could.
There are still some major difficulties to overcome though :(
-
SOUNDS REALLY GOOD PY!!!!
Really it does! We should actually chat instead of posting our ideas on the forum. The it would be much faster. Really this could be amazing!
-
Make a document, send it onto the forum or just email me it!
Oh I am so excited!
-
Now I am beginning to sound like Bots ;)
-
Aren't 64 bits for a command quite a lot?
Yes 64 bits is a lot but it is still microscopic compared to real DNA
The reason I suggest 64 bits instead of 32 is simply that VB thinks in 64 bit packages, as do all modern windows applications. The "Long" type variable is by far the fastest processed variable type in VB so using this type of variable makes the program run faster.
-
So will the reductions suggested work?
-
Really it does! We should actually chat instead of posting our ideas on the forum. The it would be much faster. Really this could be amazing!
Granted it would be faster but I kind of prefer this to be out where everybody can see it.
A document? maybe but I don't think I'm quite that far advanced with the idea just yet.
-
So will the reductions suggested work?
Please explain. You've lost me :blink:
-
Just write down what you think. Brainstorm! Havn't you learned that? Well it works for me, and sometimes amazing ideas come out!
Btw. VB thinks in 32 bit! That does windows to!
-
Yeah that is a big number, but can't we rule out some commands as impossible? Rule out others as duplicates?
Would this help reduce it a bit?
-
Btw. VB thinks in 32 bit! That does windows to!
You are probably right about that now that I come to think of it. maybe a "long" uses 32 bits and not 64. Still freaking big though. :D
Ah well, can't be right all the time. :)
-
PY I dont know what you are thinking, but take some time off, write a doc about what you have in mind, just skecth it roughly, we always get back to details latter. I would love to know (and help) what it is, but well I am not a mind reader!
-
Yeah that is a big number, but can't we rule out some commands as impossible? Rule out others as duplicates?
Would this help reduce it a bit?
Oh I see what you mean.
I think the way I see it is that duplicates would be possible but not pre-determined. I think that could be left to chance mutation.
Also variations in a specific "bit pattern" DNA strand (called a Word hereafter for simplicity) would be mitigated or compounded by the strands before and after it such that a specif pattern would actually have different effects in different parts of the DNA.
I kind of visualize a system where some Words would be like switches that activate the Word immediately following it. Others would be more like actions but the actual action would be fully contained in the word itself or in a specified register. Others again would close a conditional loop. Nested loops would be possible so behaviours could get really complex.
A little like DB still but with a lot more variability in what can happen. Also a whole lot less readable DNA code.
-
PY I dont know what you are thinking, but take some time off, write a doc about what you have in mind, just skecth it roughly, we always get back to details latter. I would love to know (and help) what it is, but well I am not a mind reader!
I will at some point.
The way I work though is to think out loud a lot and gradually let things congeal into a real plan. I don't quite feel that I'm there yet.
Talking here is helping.
-
Also a whole lot less readable DNA code.
Forget about that! When we have an DNA interprenter, we can have the reverse, a DNA parser, whatever we will called doesnt matter. What matters is the outcome of this. You ideas sound better and better. I have to go to work now, but I will think of it to see if I can come up with something to.
-
So basically you can't have the kind of DNA you are suggesting, even though it would give the most accurate representation of DNA in a sim?
But wait! I've just remembered something from a biology book I read...
DNA has an in-built redundancy to protect from catastrophic errors from mutations. Many different sequences of DNA code the same protein! Now that would definitely reduce all those possibilities. We could arbitrarily group variations together so that they code for the same environmental action.
How would that be?
-
It simple.
A codon (3 base pairs (each with 4 possible states)) give 64, there are only 20 aminoacides, the redundancy lies in the fact that many codon come for the same aminoacid.
EDIT: not come from, but code for the same aminoacid!
AH I hate when I type something wrong! :puke:
-
OK cool, could that be introduced to this idea?
Meant 'How would that be' for would that apply to the sim idea.. but v interesting, thanks [Greven]! :D
-
DNA has an in-built redundancy to protect from catastrophic errors from mutations. Many different sequences of DNA code the same protein! Now that would definitely reduce all those possibilities. We could arbitrarily group variations together so that they code for the same environmental action.
Not quite. We have to get away from anything arbitrary as much as possible.
Think of it more as a wider range of similar codes that do the same thing.
Possibly think a single specific protein being produced due to a certain combination of bits within the Word. Say protein A will be made by any combination 1011101 found within the 32 bit Word. There exists the potential of this pattern appearing a lot of times in the 32 bits. They might even overlap.
Other bit patterns can do stuff like turning protein production on or off or redirecting available proteins to muscles or fat storage or all the other stuff an organism does.
To take this analogy a step further, the entire action/reaction could be controlled by the type and amount of these proteins that are present in the organism at the end of a given action cycle. The organism can then use these proteins to power movement or feed or whatever.
-
Well hasn't it all become much much easier to do by making duplicate codes?
Other bit patterns can do stuff like turning protein production on or off or redirecting available proteins to muscles or fat storage or all the other stuff an organism does.
To hell with them for now! We would want code that is remotely readable, surely?
I'm getting thoroughly excited :D
-
To hell with them for now! We would want code that is remotely readable, surely?
Actually the way I see it, from a purely evolutionary point of view, readability of code is the last thing you really want.
We could probably rig up some kind of interpretter to allow a little bit of design and and debugging but this concept is aiming for maximum possibilities of action within a somewhat limited environment.
Basicly pure evo.
-
Can't we just go with commands -> actions (visible ones) for now? Just to get it working?
-
Can't we just go with commands -> actions (visible ones) for now? Just to get it working?
But how can we do that?
Actions can only be performed once the actual DNA has been passed through an interpretter. That has been the gist of my entire point here (and elsewhere) :banghead:
The Interpretter is the entire core of the program. without it the DNA cannot have any effect on the simulation or vice versa.
-
The problem you are describing has apparently gone right over my head; I just don't see one at all. Sure it will take a while to list all commands, assign them codes and group them together, but that's doable. :blink: Isn't it?
-
I would like to point out that while there are a finite number of amino acids used, the length of proteins constructed from these amino acids are thousands of amino acids long.
That may even be a conservative estimate.
And then there are the actual simulation problems, specifically that modelling chemical reactions realistically is really a simulation in and of itself.
So trying to get the DNA to actually cause physical changes beased on purely chemical motive forces is a bit unrealistic with the processing power available.
If that's what this thread is really about and I haven't wasted the last 10 minutes of my life reading it ;)
-
Aha but I cleverly never mentioned chemicals merely substances. And a limited number of them at that.
In my head I imaginined there being more 'clumpy' substances like soil, air etc... it might be stupid but it would mean you wouldnt need to calculate chemical processes. You could simply state the rules of interaction instead of having to calculate them.
-
But the difference from Ulciscor and PY thought is:
I understand perfectly what Ulciscor is saying, while you PY have been vague in describing your ideas (no offense).
And--->
ULCISCOR that is exctractly what I am thinking!!!!!!!!!
Ulciscor's ideas = PY's ideas = Greven's ideas => PERFECT
It seems we all see it the same way, but have explain them differently, and we therefore have misunderstood each other.
Ulciscor, you have the power of the written text, or what ever I should call it! Thank you!
just found and began reading this thread.
so just to say ...
so far ... I am in total agreement with these ideas.
this, imo, is what is needed to 'begin'.
-
I would like to point out that while there are a finite number of amino acids used, the length of proteins constructed from these amino acids are thousands of amino acids long.
I wasn't even considering attempting to model real chemistry here.
My idea is more that we would have a finite but large amount of pseudo-proteins that can be made by the DNA bit code. They do not have to look, act or in any way resemble real proteins.
Each pseudo-protein does a different thing. One provides energy for movement, one digests a certain food type etc. Once produced, they can be utilized by other parts of the DNA code.
Everything is tokenized and we never really attempt to model real physics or chemistry.
-
Aha but I cleverly never mentioned chemicals merely substances. And a limited number of them at that.
In my head I imaginined there being more 'clumpy' substances like soil, air etc... it might be stupid but it would mean you wouldnt need to calculate chemical processes. You could simply state the rules of interaction instead of having to calculate them.
PRECISELY! Well said Ulc. :D
-
great 'brainstorming' thread lads ...
enjoying it a great deal ...
and almost as excited as Greven. ;)
good on ya all ...
keep it up.
-
I'm not understanding the modus operandi of the DNA to the world. Explain it to me in terms of the current system.
Currently, DNA manipulates packets of information (memory cells) into other packets of information (sysvar commands).
Are we still doign that or comming from a new direction?
-
The problem you are describing has apparently gone right over my head; I just don't see one at all. Sure it will take a while to list all commands, assign them codes and group them together, but that's doable. :blink: Isn't it?
I can see tha nobody else seems to see this as a problem. here is why I do (again)
Sure we can make up a bunch of rules which relate DNA to action.
Sure we can list all commands etc.
Thise things ARE the interpretter.
But doing that puts us right back where everybody who wants simplicity, hates being.
All these rules, commands and stuff are the ARTIFICIAL part of the program that we need to get away from. This is where all the complaints come from.
Command X in DNA results in action Y in the sim. It is a RULE and is always enforced.
If I want action Z in the sim to happen then I need a solid rule that will link a DNA command to that action.
What we really. ideally need is a system where we have no direct control at the interpretter stage. This is where I get stuck. I don't see any way that action Z can ever happen unless the interpretter specifically instructs it to happen in that exact way in response to a specific DNA command.
It is too rigid to allow true emergence.
Please say that somebody understands my point here :(
-
Please say that somebody understands my point here :(
:raises hand: I do.
Which is why I've been saying that it's really just an argument over what level of abstraction you want. I prefer to keep the abstractio just below the level of useful behavior, because it's easier to maintain in code.
Below that I don't much care. I don't care how the bot moves, but why it decided to move now and not later. I'm more interested in behavioral evolution than phsyiological evolution.
-
Aha! I see! :D Well I agree that there are rules imposed when a command is linked to an action, but I don't think you can get around that. Although...
Maybe the command would make the organism attempt to undertake the action. Like (for arguement's sake) .up translated to a bot attempting to fire particles to move forwards. The bot would then try to do so. Whether it would succeed would depend on the factors of the environment, which would vary on the situation and would never be rigid or imposed.
I am thinking of analogies in biology. And I'm starting to think DNA is not the best way of describing bot script any more. 'Neural pathways' seem to be much more accurate, since sensory inputs or prompts are linked to some sort of output.
-
I'm not understanding the modus operandi of the DNA to the world. Explain it to me in terms of the current system.
Currently, DNA manipulates packets of information (memory cells) into other packets of information (sysvar commands).
Are we still doign that or comming from a new direction?
I am thinking along parralell lines to DB. We have to have some kind of register system like the DB memlocs otherwise no variability of commands is possible.
ie. command A could tell the organism to turn left but without some way to specify how far left it would do exactly tehsame thing every time the command was used. That would just make the DNA less flexible.
However I want to get away from the reverse polish notation stuff.
I envision each command to be simply a string of bits (possibly varying length) that contains a whole bunch of instructions that will be either carried out or not depending on whether a previous command has enabled or disabled it.
Certain instructions could (for example say) skip next command IF condition X. But all instructions in the current command would be carried out.
I haven't really fleshed out my entire idea yet, not even fully in my own mind.
-
I am thinking of analogies in biology. And I'm starting to think DNA is not the best way of describing bot script any more. 'Neural pathways' seem to be much more accurate, since sensory inputs or prompts are linked to some sort of output.
I was thinking that too.
The present DB DNA is more like a behavioural program than true DNA. It is more what the bot is thinking than what is going on in the real metabolic pathways. There is some crossover though.
Maybe we should have two parallel programs, one for behaviour (the brain) and the other for metabolism and stuff.
-
Totally agreed! I have recently been thinking that too.
The genetic stuff could handle metabolism, reproduction, and could have effects on the behavioural aspect.
The neural stuff could handle senses and actions, and could have effects on the genetic aspect.
Then there is the actual physical bot that could attempt to 'obey' the other 2 aspects, whilst also affecting them both.
Does this make any sense or is it needlessly complex? I'm fairly sure it would take an eternity to compute for each bot.
-
But doing that puts us right back where everybody who wants simplicity, hates being.
All these rules, commands and stuff are the ARTIFICIAL part of the program that we need to get away from. This is where all the complaints come from.
they do?
then I think you still misunderstand.
there is no problem with having rules ... they are essential.
let me use a real world example in an attempt to explain.
we have gravity.
if we do not have something to support us ... we will fall.
it's a rule. it isn't artificial. just how it is.
now ...
those of us who behave in such ways that allow us to fall and die ...
are less likely to survive and reproduce, eh?
and those of us who behave in ways that result in us not 'falling and
not being able to get up' ... those of us who don't jump off bridges ... will.
and as a result ... overall ... the majority of those decended from us are
going to be those who exhibit this particular pattern of behavior.
is this not so?
and so ... we might say that this is a behavior that 'emerged'.
the rule of gravity and falling was not altered or changed ...
only the behavior that resulted in falling is one that has not continued.
the behavours will evolve to conform to those basic rules ...
and I see no problem with that.
in fact ... it is these rules that will allow us to set up experiments ...
to manipulate the environment ... to alter the context ...
to impose some limitations ... WITHIN which ... behavior may be
observed to emerge.
does this make any sense?
am I saying something other than you are?
perhaps it has appeared so ... but underneath ... I think not.
where does this fit into your vision, PY? if it does.
[attempting to check out the same book and read from the same page.] ;)
-
It makes sense and is about as complex as the thing needs to be.
Add to that a bunch of flexible rules and you have something that could work.
I still have issues with limiting the possible actions in the interpretter though.
The way I see it is this.
If the interpretter is simple (say 10 possible actions) then the behaviour HAS to be simple too. After all the organism can only ever do 10 things.
If the interpretter is VERY complex then the organism can do loads of stuff in loads of different combinations.
This is the very heart of my arguments to increase complexity in order to have LESS control over the behaviour.
IMO we need hundreds of possible actions and many of them need to be very similar. then we group them in a graduation from one thing to another and allow mutation to choose which one to use.
-
there is no problem with having rules ... they are essential.
let me use a real world example in an attempt to explain.
we have gravity.
if we do not have something to support us ... we will fall.
it's a rule. it isn't artificial. just how it is.
Gravity isn't a RULE in the sense that I am talking about.
Gravity is a physical law.
What I mean by a rule is if memory location 1 has a value in then the bot accelerates by that value.
If memory location 5 has a value in, it rotates by that value.
If memory location 300 has a value in, then reproduce.
Those are RULEs of the interpretter. They are arbitrary, not physical constants.
-
Well all the movement actions can be grouped together for similarity. In fact as far as I can tell you can group all the functions together because they are based on simple interactions. Move (substance), eject, reproduce, etc
-
If the interpretter is VERY complex then the organism can do loads of stuff in loads of different combinations.
This is the very heart of my arguments to increase complexity in order to have LESS control over the behaviour.
IMO we need hundreds of possible actions and many of them need to be very similar. then we group them in a graduation from one thing to another and allow mutation to choose which one to use.
ahha!. got ya. I see now your 'more is less'.
providing a great deal to choose from ...
but allowing the 'choosing' to be a result of behavior that
works plus mutations.
the 'gradation' is an interesting idea ...
even within a given action.
perhaps any one possible action could have a 'variable' ...
so the action could be 'scaled' in magnitude ...
iow ... we have one action defined for 'move' ...
but a variable that is assigned/gets picked up along with it ...
for how far to move ...
that gets passed along at reproduction.
same with a 'turn' ... with a variable assigned for how far to turn.
so as a result, our hundreds of actions ...
could result in 1000's or 10,000's of actions ...
by adding a magnitude to them.
perhaps that is how it already works, don't know.
or perhaps this is completely off the wall. don't know that either. ;)
-
providing a great deal to choose from ...
but allowing the 'choosing' to be a result of behavior that
works plus mutations.
Surely a large % of mutations would work if sequences have redundancies.
Changing a value would make a small change to a sequence which may or may not translate to a different function.
Deleting a value would change all concurrent sequences and would likely make massive changes to the organism. But since there is a redundancy the organism might be able to manage.
-
perhaps that is how it already works, don't know.
That is exactly how it works now.
10 .up store makes a bot accelerate forward at a rate of 10.
This DNA command is passed on to the bot's descendents and is prone to mutation.
It could come through as 12 .up store
or 10 .dn store
Numerically .up is command 1 and .dn is command 2 so the two are very prone to cross mutate.
-
we have humor, but the thing is I take things to literely.
-
I'm not understanding the modus operandi of the DNA to the world. Explain it to me in terms of the current system.
Currently, DNA manipulates packets of information (memory cells) into other packets of information (sysvar commands).
Are we still doign that or comming from a new direction?
I am thinking along parralell lines to DB. We have to have some kind of register system like the DB memlocs otherwise no variability of commands is possible.
....
I envision each command to be simply a string of bits (possibly varying length) that contains a whole bunch of instructions that will be either carried out or not depending on whether a previous command has enabled or disabled it.
Certain instructions could (for example say) skip next command IF condition X. But all instructions in the current command would be carried out.
I haven't really fleshed out my entire idea yet, not even fully in my own mind.
Okay, bear with me while my concrete mind is blasted into bits and reassembled...
To me, it sounds exactly like you've just described a gene in the current system. A string of commands that are executed or not depending on wether it's been enabled/disabled.
-
But doing that puts us right back where everybody who wants simplicity, hates being.
All these rules, commands and stuff are the ARTIFICIAL part of the program that we need to get away from. This is where all the complaints come from.
they do?
then I think you still misunderstand.
there is no problem with having rules ... they are essential.
let me use a real world example in an attempt to explain.
we have gravity.
if we do not have something to support us ... we will fall.
it's a rule. it isn't artificial. just how it is.
now ...
those of us who behave in such ways that allow us to fall and die ...
are less likely to survive and reproduce, eh?
and those of us who behave in ways that result in us not 'falling and
not being able to get up' ... those of us who don't jump off bridges ... will.
and as a result ... overall ... the majority of those decended from us are
going to be those who exhibit this particular pattern of behavior.
is this not so?
and so ... we might say that this is a behavior that 'emerged'.
the rule of gravity and falling was not altered or changed ...
only the behavior that resulted in falling is one that has not continued.
the behavours will evolve to conform to those basic rules ...
and I see no problem with that.
in fact ... it is these rules that will allow us to set up experiments ...
to manipulate the environment ... to alter the context ...
to impose some limitations ... WITHIN which ... behavior may be
observed to emerge.
does this make any sense?
am I saying something other than you are?
perhaps it has appeared so ... but underneath ... I think not.
where does this fit into your vision, PY? if it does.
[attempting to check out the same book and read from the same page.] ;)
That makes so much sense that as far as I can tell that's exactly what we've been doing for the last 3 years.
All sorts of stupid behaviors are possible in the current system. Bots can eat their own babies. Bots can reproduce constantly until all descendants die of exhaustion.
The only things that are handled more or less automatically are internal matters. Feeding and storing body, etc. And even then a great deal of stupidity is allowed.
-
I am thinking of analogies in biology. And I'm starting to think DNA is not the best way of describing bot script any more. 'Neural pathways' seem to be much more accurate, since sensory inputs or prompts are linked to some sort of output.
I was thinking that too.
The present DB DNA is more like a behavioural program than true DNA. It is more what the bot is thinking than what is going on in the real metabolic pathways. There is some crossover though.
Maybe we should have two parallel programs, one for behaviour (the brain) and the other for metabolism and stuff.
Third the motion. The DNA is strictly as it now stands behavioral. Phsyiological effects should be a seperate but related idea, in a seperate but related part of the organism file.
That's sort of along the same lines as the bit string for enzymes we were talking about way back when. But broadened.
-
Well all the movement actions can be grouped together for similarity. In fact as far as I can tell you can group all the functions together because they are based on simple interactions. Move (substance), eject, reproduce, etc
The sysvars are sort of a mess, but yes, that's the basic idea. The problem is that some groups are quite self evident. All moving things go together.
There are other sysvars that lend themself less well to a single group. They could belong in one large group or another equally well, or belong in no group and are really alone.
-
ahha!. got ya. I see now your 'more is less'.
providing a great deal to choose from ...
but allowing the 'choosing' to be a result of behavior that
works plus mutations.
...
perhaps that is how it already works, don't know.
or perhaps this is completely off the wall. don't know that either. ;)
I could be grasping at straws here, but is it possible the program works more in the way you want than you think it does?
-
I could be grasping at straws here, but is it possible the program works more in the way you want than you think it does?
possibly. ;)
if it's still going to be about evolving behavior and not a combat robot sim ...
or attempting to emulate human behavior or relativity and who knows what ...
which imo distracts and complicates what we should be working towards.
so the priority hasn't changed in my mind ...
to first and foremost get a stable version that works ...
that users can ustilize to explore evolving bots ...
without having to be programming experts ...
although that to me, is also of interest.
but to explore even that part of it ...
I first need a platform that works ...
before I can play with it and tweak/recal/expand.
if I had that ...
that's what I'd be doing instead of being here busting your and PY's chops. ;)
good way to keep Ole Griz from ravaging your camp ...
is to distract him by giving him something better to do.
throw me the fish of a 2.37.4 that works as advertised ...
and I'll be happy as a bear in the woods ...
or as some swedes might say ... "a gris in shit" ;)
-
2.4 is actually shaping up on my computer to be rather stable and (surprise, surprise) rather backwards compatible. Well, with everything but sexrepro, most Multlbots, and some otehr various relatively minor features...
Just a plug ;)
Don't forget that just because users can make their own bots, it doesn't mean that evolution can't.
Speaking of which, evolution has a very sloppy coding style. ;)
-
Speaking of which, evolution has a very sloppy coding style.
which may be exactly why it works ...
and will never be duplicated ...
our ideas/concepts of what it is ...
and emulations/simulations always falling short. ;)
-
Well, Ideally Darwinbot would fall less short than others ;)
-
To me, it sounds exactly like you've just described a gene in the current system. A string of commands that are executed or not depending on wether it's been enabled/disabled
Very similar actually.
Differences are that one "gene" if you like, is capable of switching off the following "gene" in a way that is not now possible.
Also the "genes" themselves are more like pseudo-protein factories than artificial inteligences.
My thought is that actual actions could be triggered directly by the current concentrations of pseudo-proteins. Perhaps protein A makes the organism rotate left while protein B makes it rotate right. If the two are in balance then no rotation but as one or the other becomes dominant, a rotation occurs.
All the different proteins will have different effects so the overall action taken by the organism on each cycle will be a combination of all the push-pull effects of all the proteins.
You are right that this is rapidly turning into a somwhat expanded version of the bitwise enzyme system.
-
That actually sounds like a good way to handle chromosomes (remember those) with conflicting commands.
If chromosome 1 wants to go left and chromosome 2 wants to go right...
Have each gene or chromosome or whatever logical unit you want produce somethign (at a cost) that instructs the cell on what to do. It can produce many or very few. The effect on the cell is then the weighted average of all these.
-
That's what I'm thinking!
-
Good!
Why are we yelling?! :wacko:
-
Argh!
But in DB all the actions are done by some magical force that has no basis on the environment! Bots move by some force with no source! Energy comes from nowhere at the same rate at every point in the environment! Ties aren't even defined except as bindngs between bots!
The point was to make an environment that is used to FULLY interact with the bots and for them to use it to do all actions.
-
But why must we define these interactions?
Does it really matter how a bot moves? In the end we still will have a list of actions that can and can't be done by bots.
-
For a start there will be no worrying about artificial rules being introduced, which a lot of people seem to be thinking about at the moment.
Also defining abilities based on the environment will allow every possible behaviour and action that can be thought of for that environment.
-
But see that's just it. It's impossible to form a system where every possible future thing we can ever imagine the bots doing is a natural product of the rules of interactions of substances.
Why? Well, first we'd have to define what the bots even are. That would limit what they can become, which I'm not sure I like. Are the bots animals? Cells? Robots?
Second, alot of what real cells do is the result of some complex physical rules. That sounds nice at first, until you realize that complex rules means CPU time. For instance, calculating flow of medium around a flagella is a project in and of itself.
-
Why does what the bots are even matter? They are entities that can manipulate the environment in specific ways and do so based upon their DNA.
The answer to (2) is not introduce potentially complex situations. Don't model chemical reactions. Don't give the entities flagellae. Don't allow them to broadcast EM radiation. All this kind of stuff. Make available situations as simple as possible, and take a shortcut for the complex ones and (yes I'm suggesting this) impose a direct rule instead of calculation.
-
And that's different fom now how?
-
Well at the moment the environment is just a passive arena that contains the bots. All the movement, energy etc has no actual source or meaning.
10 .up store makes the bot move forwards, but the force has no source or meaning; I suppose you could say the DNA interpreter is magically moving the bots with no visible cause.
Say DNA was instead composed of more basic actions.
eject material x from rear
eject material y from front
hold substance z
This would surely allow much more freedom in programming complex behaviour? It would be more difficult to program to be sure, but would allow all sorts of complex behaviours. More importantly (for me) it would allow emergent behaviour, which interests me loads.
I'm not putting Db down, I think it's an awesome program and everyone has done a great job on it. I'm just suggesting alternate methods for make sims that are based on a slightly different concept.
-
10 .up store does indeed have a meaning.
It is just an abstract meaning. It implies a conversion of the substance nrg into an impulse, which then may or may not cause the bot to move. The amount moved depends on friction, drag, mass, etc.
Now, say we define that the bots are ejecting X out their rear causes movement by rocket propulsion (Ignroing for the moment that no creature alive moves by squirting things out because the amount of energy needed to accomplish locomotion in this matter is phenomenal (squids and jellyfish are probably the closest, but they aren't really doing that exactly)).
Let's take the process and have it occur within some "black box" that we don't look inside of. In the way it works now:
nrg -> black box -> impulse
what you're proposing:
some element -> black box -> impulse.
The only details that are different are inside the black box. But the bots don't get to tinker with the black box eitehr way. Both are just physical consequences of the world.
I just think in the end you're going to end up with more or less exactly what we have now, just with different labels.
-
OK well here's probably where we disagree about what artificial life means. Does it have to be a model of currently existing life on Earth? Or can it be any entity that satisfies the 7(?) rules for life?
But what causes the bot to move? What is the source of the force that makes it (attempt) to move forwards? What is the meaning of a force with no source? (Hehe I rock at poetry)
I'm thinking that this system will allow more realistic, non-artificial and natural behaviours than the current one. It's only an idea though.
-
But we're just begging the question.
Current version:
Bots .up'ing move forward. Where does the force come from?
You're proposing:
Bots move forward by firing something backwards, or some such. But why does this produce a forward force?
Do you see what I'm getting at?
-
Yeah I agree. You could go on like that forever.
Maybe you could state that the environment obeys Newton's laws of motion. You could also say that it doesn't. Or that it obeys different laws. Wouldn't it be interesting to see how life develops in universes with different physical laws?
Also I was envisioning how the movement and other actions of bots could affect the environment. Movement would leave behind a stream of particles which could then be added to the environment itself, and would either be used by other bots or remain there.
I might well be spouting the most marvellous crap in the world in my head I can't see why there is a problem.
-
I just don't see what it adds necessarily. It's just all different words for the same thing.
Leaving a stream of shots behind could be seen as the waste product of moving. Sort of like waste right now, don't you think?
-
Well what is waste at the moment? Why do bots need to eject it? Where does it go? Why is it bad for bots to accumulate it? I'd personally like to see these questions answered by a system that contains the rules of the detrimental effects of materials on bots.
DB is entirely bot-based. I'd like to see a sim that was at least 50% environmentally based.
I think it might be all a matter of differing interests.
-
Probably is...
In the end evolution is going to respond to whatever physical rules it can't control. Wether these are arbitrary or no doesn't really change anything for evolution. That is what I'm pointing out.
-
Right I do see what you are saying. I guess this is what it comes down to.
DB is based on bot interaction and evolution is driven by arms-races between bots.
The other method is that evolution is driven by a dynamic environment which is altered by the bots in it.
OK bots may be part of the environment but the actual space has no effect in DB apart from giving spatial boundaries.
I think seeing how populations change and adapt due to fluctuations in environmental changes would be extremely interesting too.
-
I do think that bots should be able to interact with their environment in interesting ways, but that interaction should likewise be from the perspective of the leavings of other bots, or some inorganic energy source.
Like waste being dumped into the environment should stay and not go anywhere.
-
Woohoo we agree on something! :P
I suppose I just want the environmental stuff there for completeness, even if it doesn't have any real meaning. Although I still think it might... :rolleyes:
-
Now we are right bakc were DB is now!!! Hhhmmm
Why can everybody see problems, were I see opportunity and possiblilities! Why give up, becuase it seems to be impossible?
I dont understand.
And Ulciscor, did drop this thing (not this thread because it started so promising, but know it seems the conclusion that DB is DB ;)) about discussion and trying to wake up PY and NUM (now it is only NUM I think) from their bot sleep. Alot what PY wrote here, were precise the same ideas I had for SoL, the only difference that PY stated them clearly (they (my thoughts) have been a little vague), and put them into another context.
DB's problem lies in that for at Bot to do something, the DNA have to place a value in the memory...
DNA -> MEMORY -> PROGRAM, the problem is the middle! Because, the you need 3 instructions to state this (often more, depending on the thing you want to do).
Avida f.example, uses instructions without any paramters, that is all instructions can work for it self, and will do something even when there could be parameters (this is simplified). DB has the stack, were value are placed from the DNA. That is a solution to the problem with paramters, and any instuction in DB can work without paramters, but that is not good enough.
Okay jumping to something other, but still related (I lost my point, typical me) I think it would be good if we start to reduce the number of sysvars and basic commands (that is store,or etc.) So we get a reduce number of possiblities. THIS WILL NOT (if done correctly) make DB less complex. Actually it could increase complexticty if they are working together of some sort.
I must say I dont have the solution, this was just meant as a proposal to discuss further...
-
I am not giving up [Greven]! Don't you worry. I am already pursuing this idea, and hopefully it will develop into something usable in time.
-
I didn't decide on 1000 sysvars, it wasn't even my idea.
I only got here 10 months ago.
I just try to make as many things as possible backwards compatible.
I don't think the "problem" is the memory locations. I think the "problem" is impatient people.
-
I may be dismissing ideas out of hand at the moment instead of evaluating them based purely on worth...
Perhaps suggesting changes in a more amiable manner might help :bash: (not you Ulc, sorry if I seemed a bit rough... point still stands I think though)
If the problem is in bots having trouble pinpointing the one number in 64000 that produces a result, what if we expand sysvars to a range?
Like 1 to 32 is .up, etc. etc.
-
I didn't decide on 1000 sysvars, it wasn't even my idea.
I only got here 10 months ago.
And here it goes again... Your one and only excuse! :puke:
Funny that you think it was meant as a sort of insult or something!
I KNOW you didnt design it, but you seem extremely eager to keep it that way it is.
Why not making the bots them self decide how many memoryslots they have, and which of them do what (difficult I know, but not impossible, and could add something to DB)
I just try to make as many things as possible backwards compatible.
Actually if I remember right I havent seen a single post whining about this problem.
I don't think the "problem" is the memory locations. I think the "problem" is impatient people.
Well I presume that the "problem" is me! :unsure: Well I did start my own project up, yes I think I did so, didnt I????
But well I still hope to influence the future of DB. Well you needed programmers Num, the "problem" is that you sometimes talk above peoples head, and are arrogant. I am a heck of a programmer in VB, Java, C++, SML you name it. I have from time to time tried to say I could help, but I never got any useful answers from you. It seems to me that you are the uncrowned king of programming DB, after all, why make it more difficult for your self and not add Bots code after all. It hard to read and decipher? Ask him to make it more readable, and to comment it, well I dont know. I havent tried bots code myself, or any of the newer versions, I will let that be until there exists a stable version, and when some of the major stuff get in.
Well, happy bug hunting!
:evil:
-
I do try to keep things backwards compatible. And when I don't I repent and make them backwards comaptible anyway ;)
Yes, I like memory slots being used to determine action. It's a pattern that works, and I don't see why we should change it.
-
I may be dismissing ideas out of hand at the moment instead of evaluating them based purely on worth...
Perhaps suggesting changes in a more amiable manner might help :bash: (not you Ulc, sorry if I seemed a bit rough... point still stands I think though)
Really I dont know what you have against me, but maybe beginning to treat specific people as equal members of this board, might be helping!
We are here for DB, not insulting each other, and dismissing ideas because I don not write the proper is utterly stupid, and a sign of ignorance!
-
Man, long discussion and kind of pointless and goes in circles again and again :wacko: :wacko: :wacko:
It would be a lot more coherent if instead of saying "the whole thing is wrong, the whole thing is going to crappers!", people would actually state what their exact problem is with current system, what exactly needs to be changed and why they think it would be much better. :idea:
-
We are here for DB, not insulting each other, and dismissing ideas because I don not write the proper is utterly stupid, and a sign of ignorance!
You have a very combative tone much of the time. The sort of tone I don't respond well to. (THat sounds like a threat doesn't it :D )
-
Man, long discussion and kind of pointless and goes in circles again and again :wacko: :wacko: :wacko:
It would be a lot more coherent if instead of saying "the whole thing is wrong, the whole thing is going to crappers!", people would actually state what their <b>exact</b> problem is with current system, what <b>exactly</b> needs to be changed and why they think it would be much better. :idea:
Best idea I've heard all day ;)
But then, I"m a math major. I live on examples :)
-
I don't recall saying anything was wrong. I don't remember suggesting anything should be changed. Maybe suggestions wasn't the best place for this thread; sorry about that, if people want it moved or deleted then go ahead.
-
Okay Num is you think I am combative because I say that I have tried to wake you and PY up from your bot sleep, comeon. We both know that I have made this point a million times before, it's no secret. And it were only meant as a metaphor! Well I might be combative, but your are arrogant. That is what I dont respond well to. We have had this one before too.
-
No, you're exploring a thought path and this is as good a place as any.
I just think you may be underestimating the difficulty of having all bot mechanics emerge as a consequence of material interaction.
-
Ulciscor, they refer to me, not you. The black sheep or whatever it is called in english, for the one who always makes trouble!
-
Okay Num is you think I am combative because I say that I have tried to wake you and PY up from your bot sleep, comeon. We both know that I have made this point a million times before, it's no secret. And it were only meant as a metaphor! Well I might be combative, but your are arrogant. That is what I dont respond well to. We have had this one before too.
Not just that.
When I released 2.4 way back when you were like "WTF is this fast math crap?" Which was right, it was slower than doing it through VB, but there were more, um, tactful ways to say it.
I could go back through and create a list if you like. ;)
-
:( What is with everyone? Either everyone is taking things the wrong way or everyone is being blunt and ruthlessly-to-the-point.
-
Possibly.
Havinig basic design philosophies criticized on multiple fronts at multiple times is frustrating to moi. Especially when ways to fix it aren't articulated explicitly.
So over time lots of such jabs adds up to overwhelming frustration and I become less amiable than I am ordinarily.
-
Okay Num is you think I am combative because I say that I have tried to wake you and PY up from your bot sleep, comeon. We both know that I have made this point a million times before, it's no secret. And it were only meant as a metaphor! Well I might be combative, but your are arrogant. That is what I dont respond well to. We have had this one before too.
Not just that.
When I released 2.4 way back when you were like "WTF is this fast math crap?" Which was right, it was slower than doing it through VB, but there were more, um, tactful ways to say it.
I could go back through and create a list if you like. ;)
No I did not! I did point about that it had an error rate of x%, if you didnt know that! Then I tested it, and found out that is actually was slower than the normal VB squarroot function, which was in the best interest for DB. I my post a very not at all combative of any sort! I did test it, and gave you the results.
-
Sorry. This wasn't a criticism of DB, just a suggestion for a possible alternative. This was a sucky section to put the thread in.
-
Havinig basic design philosophies criticized on multiple fronts at multiple times is frustrating to moi. Especially when ways to fix it aren't articulated explicitly.
Well for me I mean this as a kind of dialog between all of us! I state something that I think should be changed, trying to give some *basic* thoughts about it.
Nothing speciel, but nobody seems to respond to anyting at the moment!
And all I get is -> THAT IS CRAP! WE DONT WANT IT, WE DONT USE IT -> fuck off Greven... (well maybe not so harsh ... ;) )
-
No I did not! I did point about that it had an error rate of x%, if you didnt know that! Then I tested it, and found out that is actually was slower than the normal VB squarroot function, which was in the best interest for DB. I my post a very not at all combative of any sort! I did test it, and gave you the results.
You were rather sketpcial from the start. Not like "is this really necessary" skeptical mind you...
If I'm the only one who has ever read you that way it could just be me. If so I apologize. Either way it pushes my buttons.