Code center > Suggestions

New tie structures

<< < (3/5) > >>

Numsgil:
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:

--- Quote ---Perhaps we can use positive numbers for tie phase, and negative values for the tie address in the internal array.
--- End quote ---
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:
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:
I believe it's easier for bot writing and mutations too.

PurpleYouko:
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: ---cond
-1 .nrg readtie 5000 >
start
-1 -1 1000 writetie
stop
--- End code ---

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: ---cond
' your condition
start
-1 settie
stop

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

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)

Navigation

[0] Message Index

[#] Next page

[*] Previous page