Author Topic: New tie structures (Read 7687 times)

Numsgil · « **on:** June 10, 2005, 12:36:23 PM »

Quote

That is going to screw up the .tielen1, .tielen2 etc. format.

I noticed that too. Whatever system we come up with needs to be independant of the number of ties the system allows. That is, scalable.

I would prefer a system with a minimal number of sysvars, and have some command to change which tie is being read from/written to at the moment.

Like:

set tie Y
read from tie
write to tie
switch to tie X
read from tie
write to tie
swtich back to tie Y
read from tie
write to tie

Like that.

Advantage is that mutations are more likely to keep tie actions consistant. If you lost the switch to tie X command, then all your tie X commands are now being applied to tie Y. And vice versa.

PurpleYouko · « **Reply #1 on:** June 10, 2005, 12:48:41 PM »

Right.

It isn't quite that simple though. It would be great to do it that way but in order to do so we would have to work the tie comunications sequentially directly from the DNA parser before it goes to the main loop.

We seem to be moving more and more stuff into that part of the program lately.

Possibly we need to have a sub array of ties that is manipulated just line the memory cells are. That way each tie can be addressed internally (1-10) and externally (1-32000) on every cycle. Values for transferred data and target location can be set within the array as the DNA is parsed then the actual comunications take place in the main loop.

Yes that sounds OK I think. :D

Still working on the exact details but it should be greatly streamlined over the present system

Numsgil · « **Reply #2 on:** June 10, 2005, 12:53:30 PM »

So store the information that is being passed back and forth in the tie and then apply that to the bots during the update robots cycle?

That would work well I think. Conflicting commands can be solved in the same manner I was planning on resolving conflicting stores, either chose one randomly or have smaller values take precedence, or some mixture of the two.

In a related note, I think we can get rid of all those trefvars if we can figure a way to allow the bot to say "what is at memory location X in the bot through the current tie?". Perhaps a command instead of a sysvar.

PurpleYouko · « **Reply #3 on:** June 10, 2005, 01:23:44 PM »

The trefvars are a little tricky. I was never entirely satisfied with them.
I am also not too keen on having to go through a 3 step system just to comunicate a single value through a tie.

456 .tienum store
-1 .tieloc store
-1000 .tieval store

seems like a complicated and long winded process to feed through a tie with a phase of 456.

something like a multi-part command which stores values directly into a tie array could work better.

take this as an example.

-1000 .tie#456#-1 store

this structure would store the value -1000 directly into the tieval location of a tie with a phase of 456 ready for delivery to the -1 location of the target robot in the execution cycle.

the .tie#xx#xx section of the command is no longer a sysvar but is actually a pointer to an array location within the new tie structure. The individual value can still be mutated but using such a system would more or less insure that tie communications become a relatively simple one step deal.

Numsgil · « **Reply #4 on:** June 10, 2005, 01:31:23 PM »

But you're still specifying a tie phase implicitly. I think the tie phase should be set somewhere else and then all the ties commands just use that number. Somewhat like now, but changing the number will reset all the tie vars and commands, saving the commands you issued to a command stack somewhere.

And also, 32000 tie numbers just is too much. Tiepres helps, but really you only need a couple, maybe 20 at most. That makes using ties for mutations more likely.

something like: ".body readtie" to return *.body of the bot through your currently set tie. (readtie is a command)

And 20 .fdbody writetie to send a write command. That way you can read and write using as many different ties and bots and locations as you want.

PurpleYouko · « **Reply #5 on:** June 10, 2005, 01:47:22 PM »

Quote

And also, 32000 tie numbers just is too much. Tiepres helps, but really you only need a couple, maybe 20 at most. That makes using ties for mutations more likely.

I disagree on this point. 20 just makes it way too easy to randomly find the right one. And for any other purpose than feeding through ties, it isn't going to make much difference if you have 20 options or 20,000 options.

I prefer to be able to address the tie phase directly from the command rather than have a single command that resets all of the subsequent tie functions....
unless...
You mean to use the change address commands in a sequential fashion so that you can address a certain tie for a while then change to another and do some actions on it then go to a third one and so on..
How would that work with a simultaineous or parrallel processed genome though?

The other point is that for things like setting tie lengths and angles, we can use the internal array which will only have 10 values. That method doesn't use phases at all but just directly addresses your own tie. For this to work, each tie needs to keep its assigned value and not be shuffled when a tie is lost so it might require some minor reworking.

this would work very much like the (apparently) ill fated .tieang1,2,3,4. commands.

628 tieang#1 store would set the robot/tie angle of internal array tie number 1 to an angle of 628 (directly away from the tie)

300 tielen#9 store would set the length of internal array tie number 9 to a length of 300

There are two alternative ways to address ties in this system and the old system would still work also so backward compatability would be good. The only thing lost would be the specific 8 sysvars that directly address the tie angles and lengths. Not a great loss since few (if any) robots have been made with these yet

Numsgil · « **Reply #6 on:** June 10, 2005, 02:02:53 PM »

Quote

You mean to use the change address commands in a sequential fashion so that you can address a certain tie for a while then change to another and do some actions on it then go to a third one and so on..
How would that work with a simultaineous or parrallel processed genome though?

That's exactly what I mean.

Something like this:

cond
start
1 settie
.nrg readtie
stop

cond
1000 <
start
1000 -1 writetie
stop

cond
start
2 settie
.body readtie
stop

cond
1000 <
start
1000 -1 writetie
stop

Then we just have the ties store what the bots are trying to do with them, and apply it after all bots have had a chance to run their DNA.

My main concern is how likely a bot is to actually get the necessary commands to feed through a tie. Just randomly mutating for a while it should be possible to form a tie (already does) and then all you need in this system is to have 1000 -1 writetie (which is still somewhat unlikely, but much more probable).

We could have tie number default to 1 if no settie command is set.

Quote

Quote
And also, 32000 tie numbers just is too much. Tiepres helps, but really you only need a couple, maybe 20 at most. That makes using ties for mutations more likely.

I disagree on this point. 20 just makes it way too easy to randomly find the right one.

Currently tiepres lets you find the tie of any feeding tie bot. The bot can compensate by firing a new tie every cycle.

So if we just prevent a tie from registering for a cycle if you didn't fire it, we get the same effect, without the need of complicated numbers that the bots aren't likely to develop.

this could eat food:

cond
start
.tie inc
-1000 -1 writetie
stop

which is much more probable to evolve. (only 5 commands, not interdependant)

PurpleYouko · « **Reply #7 on:** June 10, 2005, 02:40:06 PM »

Are you making a differentiation between internal tie array values (1-10 ties) and programmable tie phase (1 to whatever)?

For instance I don't think a robot should be able to feed through a tie just using its internal tie address as this is often going to be different than the robot at the other end of the tie is using to address the same tie.

for example, If bot one has 3 current ties numbered 1,2 and 3 (internally), then he shoots a 4th tie at a target bot (number 4 internally). The target bot has no ties so the tie that hits it becomes number 1 on his internal array. Both robots can now control some aspects of this tie using their internal structure but both use a different ID to do so.

However if the tie was fired with a phase of 25 then that is the value that will be returned by *.tiepres and is the value that will be used by both bots to feed or leach.

As far as the syntax goes then I don't really see the advantage of having an active tie then accesing it for a while with other commands.

your suggestion

Code: [Select]

.tie inc
-1000 -1 writetie

As you say, this has 5 sections and relies on a value to be present in .tie. Presumably firing a tie by storing a number into this will also set the value for later use and will not be erased until it is overwritten.

Yes it works pretty well.

Now look at this idea. (slight modification to bring the two ideas a little closer)

Code: [Select]

-1000 writetie#1#-1This has 2 sections with the second section being made up of 3 parts that cannot be split further. There will always be a number after each hash and they will be 100% mutatable
To take this a step further, .tie could be tied into the first hashed number so that this number is set whenever a tie command is issued. It now becomes very easy to mutate a command that will write to a tie. It only requires a single command preceded by a number.
Also each instance of this is independent of other "settie" commands.

Not sure about auto setting the value though. I just thought of some reasons why that wouldn't be so good. just let it default to 1 and -1 and you have easy tie feeding through tie phase 1 that could very easily evolve.

Numsgil · « **Reply #8 on:** June 10, 2005, 03:26:34 PM »

I was imagining that the number you use to fire a tie is more a relic than anything. As long as tie feeders still get that one cycle free feed before the prey can respond, just letting bots address ties through their position in the internal array seems simpler, more robust, and easier to mutate.

It's like that infomertial. "Just set it, and forget it". If you never change the tie you're focusing on, all tie commands use the first tie in the array. So all a bot has to do is store positive numbers to .tie to form a tie (the numbers don't matter anymore, or maybe they determine tie type) and then use a number -1 writetie command.

Backwards compatibility can be preserved with some kind of DNA converter. It depends alot on the actual implementation. But this is definately an instance I'm willing to "break" old bots for the sake of new features.

My only point I haven't made yet is on syntax.

writetie#number1#number2 looks frightful, and doesn't inherantly do anything that the stack can't handle.

"number2 number1 writetie" works just as well, and sticks with the current coding structure.

And that's all I have to say about that. We should probably start a new thread in suggestions forum and let people vote on a particular implementation.

PurpleYouko · « **Reply #9 on:** June 10, 2005, 03:58:00 PM »

Quote

writetie#number1#number2 looks frightful, and doesn't inherantly do anything that the stack can't handle.

Yes it does look a bit scary. I am not married to the idea anyway. It was just something that I threw together.
It does do one thing that the stack can't. It would fix the usable numbers in place into a single very short command structure rather than relying on external settings.

OK so a default of one in .tie would work just fine and would probably be very good as far as letting bots access what is most likely their only tie.

However I am definitely against discarding the old tie structure entirely since it is able to do a few subtle things that will be impossible using a new internal array address system exclusively.

Currently it is possible to use a gene such as

Code: [Select]

cond
start
5 .tie store
-1 .tieloc store
100 .tieval store

Doesn't look like much at first glance but what if this is a Multi-bot with several ties that mostly have different numbers but has two in specific strategic positions that share the same phase?
Then this particular gene will send energy to both of these ties in the same cycle from a single command.

There are many instances where this kind of behaviour is extremely useful. For instance, most bots can feed from multiple ties at once because they all share the same phase address.

In complex MBs this is just about the single most useful feature that I have found with the way ties are now.

Admitedly some of these things can be replaced by sharing but then that is designed to only work with mature MBs and not with quick hitter tie feeders.

And what about deleting ties? getting rid of 10 seperate ties with internal array addresses would take 10 seperate operations.

1 .deltie store
2 .deltie store
etc.
etc.

With the existing system, 10 ties that all have a phase of 15 can all be deleted at once by a single command.

15 .deltie store

Doing away with the old system in favor of a new one would in many ways make MBs harder to use and to evolve rather than easier.
I think we should be able to work out something pretty awesome from the ideas that we have been throwing around, but it can't entirely replace all the old stuff. It should compliment it and give alternative paths to the same end but never totally replace it.

Numsgil · « **Reply #10 on:** June 11, 2005, 12:39:55 PM »

Some good points, I can see why you'd want a tie phase.

But 32000 is still way overkill. Perhaps we can use positive numbers for tie phase, and negative values for the tie address in the internal array. If a number's absolute value is greater than a certain value, we can use modular math on it (think of it like "hey, there's a tie at X degrees". If X is too large, you've just spun around.

PurpleYouko · « **Reply #11 on:** June 11, 2005, 03:38:04 PM »

Quote

Perhaps we can use positive numbers for tie phase, and negative values for the tie address in the internal array.

Now that is a good idea.

How about we use -1 through -10 to address ties internally and 1 through about 200 to address tie phases. (is 200 more reasonable? Don't see the difference really other than making it more difficult to mutate the value by limiting it)

You can then create a tie by storing any value you like (within these bounds) into .tie.
A negative number sets the address in the internal array and sets the tie phase as default of 1. If the address is already taken then just bump it up 1 to the next available slot.
A positive number sets the phase the way it always has done and stores the array address in the first available slot.

I still favor a single step tie command over setting the active tie then doing stuff with it.

Something like 300 .tielen10 store could be used to set the length for a particular tie in the array and this can also be done by the old system as x .tienum store x .tielen store
The parser can easily be made to recognise a number immediately after the sysvar .tielen. The values can then be stored directly into the tie array rather than the memory array.

The more complex functions like transfering data are still going to be tricky.
We need to address the tie, set the memory location and set the value to place in it. 3 steps that have to be perfectly set up in order make it work properly.

The writetie command that you suggested might work if we set it up right. It could be made to work with 3 values from the stack perhaps so that a line of code such as 25 -1 1000 writetie would write a value of 1000 (.tieval) into memory position -1 (.tieloc) using tie phase 25 (.tienum). This would also work with a negative value in the tie phase position to address the internal tie array position.
writetie would work just like store except that it stores into the tie array ready for execution in the main loop of the program.

Again the old system is preserved to run concurrently with this so that alternate DNA codes will get to the same place.
I think it much more likely that a system like this could evolve into something useful

How does that sound?

Numsgil · « **Reply #12 on:** June 11, 2005, 04:16:29 PM »

Sounds like we're pretty close.

I would have values too large be scaled back, so a tie address of 300 addresses tie 100, etc. That helps mutations develop that can use the ties. Also, I would prefer 100 tie phases to 200, but either is within my realm of acceptance. Better 1% or .5% chance to guess right at random than .003%

And then the only real difference of opinion I have is that I would still split the tie address from the write tie command.

In your system, to do a string of writeties and readties from the same tie (which is what you're usually doing), you'd need to do:

25 -1 1000 writetie
25 .up 200 writetie
25 .body readtie
25 .nrg readtie

etc.

whereas in what I propse, you just need to do:
25 settie
-1 1000 writetie
1 200 writetie
.body readtie
.nrg readtie

You begin saving 1 command for every tie manipulation after the third, and also encrourages commands that manipulate the same ties to stay together. If 25 mutates to -2, all those other tie commands also switch targets, which, I think, encourages more cooperative command evolution.

I believe it's easier for bot writing and mutations.

We could even do both. One command takes three values from the stack, the other takes 2.

Botsareus · « **Reply #13 on:** June 11, 2005, 05:58:33 PM »

I believe it's easier for bot writing and mutations too.

PurpleYouko · « **Reply #14 on:** June 12, 2005, 01:31:49 PM »

definitely seems like we are converging on a workable system and as you say we could easily use both idea (for more complexity).

If the parser finds a value in .settie then use the top 2 values on the stack, otherwise use the top 3.
Using .settie is great if you want to address the same tie many times but what if you want to give a single command to multiple ties in the same cycle...

That way your method uses twice the commands as mine.

Then again, if it is the same command then using the tie phase will get all ties with that phase anyway so that will save even more.

To be honest I could live with either solution or both.

As to the tie phases being limited to 100. No problem with that. I don't see an advantage to doing so but I also see no reason not to. How about we use a mod function rather than scaling (settie value mod 100). This allows the mutater to run all the way up to 32000 but the value can only be 0-100. Using this then if the value in settie increases by 1 due to mutation then it will actually change wheras if it is scaled then it wil need to rise or fall by a large number (320 actually) before a visible change happens in the DNA.
Mod does have a drawback though. When a value of 99 increases by 1, it becomes 0.

Ah well! Them's the breaks I guess

How about the readtie command?

I was thinking that each tie would have a specific location in its array that would hold a read value by using the readtie command.
That way -5 1 readtie would store the value in the tied robot's .up location into the array position in tie no -5
Similarly
-5 settie
1 readtie
would do the same thing
Alternatively (and probably better) this command could simply place the value on top of the stack for immediate use.

Code: [Select]

cond
-1 .nrg readtie 5000 >
start
-1 -1 1000 writetie
stop

This gene would feed from a tied robot if it has more than 5000 energy. Alternatively this would work as a 2 gene segment usint settie.

Code: [Select]

cond
' your condition
start
-1 settie
stop

cond
.nrg readtie 5000 >
start
-1 1000 writetie
stop

I prefer the former as it is more compact and only requires a single gene but both would work and are a lot simpler than the present method.
The second version has the advantage of being able to set the settie value to different numbers depending on conditions and then use the same gene to actually feed.

Either or both could be programmed reasonably easily.

Let's go for both I say! B)

Darwinbots Forum

News:

Author Topic: New tie structures (Read 7687 times)

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

PurpleYouko

New tie structures

Numsgil

New tie structures

Botsareus

New tie structures

PurpleYouko

New tie structures