Contiguous free sysvars space?

[MacadamiaNuts]

I was wondering last afternoon about the requeriments for coding a rudimentary mapping system --remembering where shapes are and where food or enemy was found.

I think I could come up with something very primitive, but I would need some amount of contiguous free sysvars (def-ing them wouldn't help). I'm a bit lazy to track which memory locations aren't meaningful in the last version. Are there any +81 contiguous free sysvars below racial memory?

If not, could a safe extended memory byte array be added that could be accessed through an operator? Like:

x y readxms -> puts the xms(x,y) value in the stack.
value x y writexms -> puts value in the xms(x,y) safe memory location.

A 16 x 16 byte array would be good enough.

[EricL]

You could use 50-178 inclusive.  I plan to keep that range free for the forseeable future.  Gives you 128 contigious locations...


I've been noddling a little bit on extended memory for things such as getting refvar info on everything in sight in any eye all in one cycle or controlling N ties all in one go (or remembering thigns as you proporse) but the ramifications in terms of addressing need to be well thought through.  For example, I think we want the probability of a mutation addressing this space to be the same as the probabiltiy of addressing any other memory locaiton.  Anyway, I've not put enough thought into it yet.

[MacadamiaNuts]

Thanks! That'll be good enough. I just wanted them to make a hot/cold map so they generally avoid unpleasant areas.

Now I need to figure how to combine the unknown map size factor and map knowledge sharing for bee behaviour.

[EricL]

With respect to extended addressing, one kind of proto idea I have is to enable the use of tied bots as a receptical for storing information.  Imagine if we modified tmemloc and tmemval (or invented a new mechanism) so as to allow for "dynamic" real-time addressing of a tied bot's memory.  That is, changing .tmemloc would instantly change .tmemval in real time right there, that cycle, for all the following DNA.  In this way bot A could in theory address as many different locations in Bot B's memory as it wanted in a single cycle.

This strikes me as a rather general purpose mechanism (I don't claim to have thought through all the ramifications) that would encourage cell specialization and multibots and in particular, does not mess with the foundations of memory addressing.  Info shots, altzhiemers, refvars and so on all work just as before but it a bot wants to say, maintain revar info about every bot it's ever seen, it now has a theoritical way to do it I.e. bud off additional tied cells whose primary purpose is a memory receptical for use by the "brain cell(s)".

Just a proto idea for now.

[EricL]

Now I need to figure how to combine the unknown map size factor and map knowledge sharing for bee behaviour.

.xpos and .ypos now range 0 - 32000 for all larger fields.  I've been wondering whether I should do the same for smaller fields where the actual field dimensions are < 32000.  That is, force the range for .xpos and .ypos to be the same for all field sizes, even small ones.  This way, you could chop any size field into 128 locations and use the same the exact x and y values for defining hot spot granulatiry.  You would just end up with courser grains on larger fields....

[Numsgil]

With respect to extended addressing, one kind of proto idea I have is to enable the use of tied bots as a receptical for storing information.  Imagine if we modified tmemloc and tmemval (or invented a new mechanism) so as to allow for "dynamic" real-time addressing of a tied bot's memory.  That is, changing .tmemloc would instantly change .tmemval in real time right there, that cycle, for all the following DNA.  In this way bot A could in theory address as many different locations in Bot B's memory as it wanted in a single cycle.

This strikes me as a rather general purpose mechanism (I don't claim to have thought through all the ramifications) that would encourage cell specialization and multibots and in particular, does not mess with the foundations of memory addressing.  Info shots, altzhiemers, refvars and so on all work just as before but it a bot wants to say, maintain revar info about every bot it's ever seen, it now has a theoritical way to do it I.e. bud off additional tied cells whose primary purpose is a memory receptical for use by the "brain cell(s)".

Just a proto idea for now.

I'm planning this for DB3 actually.  For it to work right, there are some gotchas as far as coding it so that it's independant of the order bots are executed.  But like you say, it opens up all sorts of neat things to play with.