Variable length arrays for the bots

[Numsgil]

This isn't as much an issue now, but playing around with the idea of bot IDs (as in "Bot 10456 attacked me.  Everyone attack him if you see him!"), variable number of ties, and other similar issues having a "foreach" type loop in the DNA would be very useful.  This only works if this "foreach" was performed on an array.

We could have, say, 10 circular arrays of unlimited length that bots can write to that persist across cycles just like memory locations, addressed by memory locations -1 through -10.

I haven't worked out all the specifics, but something like the following is my goal (in pseudocode)

if a bot is attacking me that's supposed to be a conspec:
store this ID in .Cheaters array

...

if I see another bot:
foreach ID in .Cheaters array, if other bot's ID = ID from .Cheaters array, attack this bot or run away.

[Sprotiel]

I don't think it's a good idea. Most likely, there will be evolved bots that write to it every turn. Suppose there are 100 of them, living 10000 turns on average  and that they use this foreach every turn. This means you get one million tests to perform every turn... A high price to pay for a dubious benefit!

[Endy]

Maybe limit the array size to something smaller. I don't think that they need to have a completly unlimited storage potential, just be able to hold multiple values in a single location.

[Numsgil]

Certainly not more than probably 100 locations.  I'm imagining a case where bots want to do something to every tie, or every eye, etc.

[EricL]

Several things.  

First, I don't think we need invent new data structures such as new stacks or queues or arrays.  I think it might be sufficient to simply add a new command or two which allowed for addressing and operating upon multiple existing memory locations at once.  For example, lets invent the operator ** and say X Y ** means "memory locations X through X+Y inclusive.

Thus, we could do something like

cond
.eye1 9 ** 50 >  
start
blah blah
end

The condition would be true if any eye value was greater than 50.  I think this could be pretty easily implemented by pushing a magic value representing the ** command (or other such commands) onto the integer stack.

We could add other commands, for example **=, where X Y Z **= meant "the first memory location between X and X+Y inclusive where the value equals Z.   Thus Num's could store the IDs of the "bad" bots in the genetic memory locations as

*.refID 971 20 0 **=  store

and test for them as

*.refID 971 20 ** =

Second, I think we have to differentiate between operating upon multiple existing memory existing locations where the results are already defined, such as above and the need to expand the grammer into new territory such as operating on multiple ties at once where there isn't a paradym in place for addressing all ties at once.  I would seperate the two issues as they may have different solutions.  Things which are addressed via a level of indiretion through a single sysvar such as .tienum may require a slightly different mechansim.

[Endy]

I like the idea about expanding the language like you're suggesting, but we need some method to efficently store/retrieve large amounts of information. Mainly I think this would be handy for behavioral information, but it would probably also be useful for other things.

[Numsgil]

My main issue at the moment when I've tried to write imaginary DNA to test ideas I've had is that it's very difficult to build a way at the moment to have variable length arrays.

For instance, I could do something like: array starts at X, length is stored in Y, but then how would I write code in the current language that can act on all elements between X and X+Y (+1 depending on how you count).  Usually you'll have some function that you'll want to use on each element in your array.

And then, assuming that I do have a way to do this, I need to be sure that my array doesn't cross over into sysvars, ie: protected memory.

And then, this isn't a very evolvable structure.  I think if there was a very easy way for evolution to be able to operate on large, potentially variably sized arrays this would be a boon.
---------------------------------------------------------

Expanding on your idea Eric, and incorporating codules which is where this is really going to be useful anyway, I would say that if we go that route, we'd need operators like:

[array] codule calleach - passes each element of [array] (I'm ignoring for a moment how the DNA addresses arrays) to seperate instances of codule.

But in the end, I think using the classic "flat" memory method of DOS and the old days is a poor idea.  If I were to completely reinvent the DNA, I would provide baseline support for vectors (2, 3, and 4 dimensional), matricies (2, 3, and 4 dimensional), scalars (floats, integers, types (say for instance, colors), fixed point numbers between [0,1] or [-1,1], etc.), stacks, queues, lists, and maybe a few other things.

But then, I have no idea what it would mean to add 3.6 and blue.  So I think our flat memory will exist for a while longer