Would a *.subspecies sysvar be facist?

[EricL]

I am maintaining a "subspecies" number internally for each bot in order to implement the new Species Diversity graph.  Bots inherit the subspecies of their parent, but it gets set to a new value (based on a per species counter) when a mutation or virus infection occurs.

The new chart (2.43b) counts the number of unique subspecies within a "species".  

Is there any interest in exposing this as a sysvar?  It would allow a bot to determine if it was "different" from another of it's same "species" without performing a detailed DNA analysis.  Additionally, by comparing the two numbers, bots could potentially make some rough, fuzzy determination as to how different.  (What the difference actually indicates is the number of mutations and virus infections that have occurred to all members of the species between the two events that set the two bots own subspecies number.)

One can imagine bots using this for policing their own genetic purity: parents could kill their mutated children or potentially attack other members of it's species which have a larger/different subspecies value then their own under the assumption that they are more mutated (or have been virus infected) from the "pure" 0 valued subspecies value all bots start with at the beginning of a sim....

[googlyeyesultra]

That would make it a bit to easy to determine whether or not someone else has been infected by a virus. Thus, another bot could easily be used to eliminate all infected bots, without the virus being able to do anything.

So, my vote is no.

[Numsgil]

Generally the philosophy thus far for sysvars (at least as long as I've been around) is to give bots limited and imperfect knowledge about their surroundings.  Things that a human or animal or bug or whatever could gather about their environment by being placed in a similar position.  As I see it, there are three degrees of information for sysvars:

1.  Observational data about a bot's surroundings.  Such as what it can see, in/out variables, etc.  Things that a human or other animal (bug, bacteria, whatever) could determine at a glance in the bot's position.

2.  "Hidden" data about other bots, such as their nrg, body, etc. levels,  Memloc/memval, refeye.  Things that a bot can figure out if they could peek into the other bots memory array.

3.  Global data that an animal similarly placed couldn't possibly determine, or shouldn't have to determine.  Things like maxvel, for one, xpos and ypos to a lesser extent.  That's probably about it.

I'm strongly against moving up that list without some very good reasons.  Maxvel, for instance, is a limitation of the system, so the idea is that it isn't fair for a bot to be subjected to that law without some heads up.  I was never a fan of xpos and ypos as absolute references.  They were added for early antbots.  But even here, the argument went that real ants use pheremone trails and polarized sunlight to navigate.  We could simulate those things, we just can't/don't want to right now.  If you haven't, try going to the old forum and reading through the early development reasoning behind different features we take for granted.

Even hidden data I think gives too much information about the system.  You shouldn't be able to tell by looking at a bot if it's dead or alive, for instance.  You should have to do some reasoning (well, it hasn't moved in a couple of cycles, and when I poke it, it doesn't react).  And the whole refeye/myeye thing is indefensible when you really examine it.  Conspec ID should be handled with in/out pairs.

The lower level you keep things, the more possibility there is for bots to make mistakes, or take advantage of each other.  A bot could play dead, for instance, and wait for another bot to drop its guard and then attack it.  Bots can try to spoof in/out conspec alot easier than the refeye/myeye system.

For the new version, I'm reworking things to be as low level as possible.  I'm trying to find ways to eliminate the need for refnrg, etc.  Keep things strictly based on information immediately available to bots.  What you're suggesting here is something I'd put in the third tier.  It provides information that a human in a similar position would have no way of knowing.

Trying to cope with mutated offspring is an interesting and rewarding area for bots to try to figure out.  Even telling if your kid is lame requires some good coding.  I don't see a reason to give bots this information when with some good work they can figure it out for themselves.

That said, I do think that using shepherd bots in evosims as a poor man's scripting system is extremely useful.  These shepherd bots are less animals and more forces of nature, so I concede that in this case giving these bots better information is valuable.  Perhaps set up some shepherd sysvars that are deactivated by default, but can be enabled for shepherd bots.

[EricL]

So, I strongly agree with this philosophy for the most part.  

Regarding your first sysvar catagoy, I have referred to this as the Principle of Locality in other posts and strongly agree we should adhere to this prinicple.   I would similarly be quite happy to see global information such as xpos and ypos go away (although agreed, perhaps not until there is substitue for ant bots which obeys this principle such as ability to leave phermone bread crumbs which can only be observed locally, as you suggest).  I agree .totalbots and .totalmyspecies are and should be special exceptions for use by shepard bots and would be happy to see them disabled by default and/or otherwise restricted or limited for exclusive use by bots whose purpose is to be a force of nature (love that term).

Regarding the second, I think about this in the following way.  A bot's mem array is not just hidden state, its part of its morph and I would submit that direct interactions on bot mem arrays are actually more "natural" for bots then are indirect interactions via simulated physical intermediaries (shots, collisions, vision, etc.).  We simulate phenotpic physicality, but we do so primarily for reasons having to do with evolving bots in an environment intuitive to humans, one that eases human observation, I.e. allows humans to more easily observe and recognize intersting behaviour or adapations.  Imagine how difficult it would be to pick out a new adapatation in a Core Wars style Alife sim with no simulated physical morph!  But the truth is our bots are ditigal creatures residing in a digital world and I thus have no issues with enabling interations "native" to such an existance.  In fact, I could make a case (elsewhere) that moving in this direction is the only way we will ever overcome the "collision detection scalability" problem.  The physicality simulation is for us humans.  It defines the complex set of interactions in how bot mem array values effect one another (based on the simulated physics) but it is not really the native environment of digital Alife.   So, thinking about it this way is how I justify and even strongly support direct mem-array operation/observation.

Regarding the third, I think we are half pregnant today.  We have .maxvel.  Why don't we have .zaxisgravity, .yaxixgravity, .fluidresistance, .staticfriction, .dynamicfriction, .xfieldsize, .yfieldsize, etc.?   Bots should either be able to know a lot about the global environment or nothing.  I prefer nothing, which is in keeping with your low level approach.  They have to figure it out for themsleves through trial and error and the indirect impact such things have on their state array.  Thus, I would be happy to see .maxvel go away along with .xpos and .ypos.

I actually put .subspecies into the second catagory, not the third.  We are maintaining it as per bot state internally, as we do a lot of other stuff, some of which we expose.   I think the question is simply whether we want to expose that state to the bot (and to others) and allow DNA to potentially use it or not.   There's a bunch of state we don't expose today.  Bot number for example or species name or generation or number of mutations.  There are things we do expose that don't stike me as being part of a simulated physical morph, such as .kills and .refkills.   Again, kind of half pregnant.  I'm not strongly advocating exposure of .subspecies, but I do think it is valuable to discuss what our guiding principles are regarding what per-bot state gets exposed and what does not.

[Jez]

Generally the philosophy thus far for sysvars (at least as long as I've been around) is to give bots limited and imperfect knowledge about their surroundings.

Nums, Eric, I agree, anything, like instant trigonometry, that gives bots a perfect view shouldn't be. I like imperfection, it's more realistic.

.subspecies devalues all the recognition systems for a start.

[EricL]

.subspecies devalues all the recognition systems for a start.

Not to get too far back on my high horse, but I don't see that it does.  Remember, a bot's subspecies number is species relative.  To be clear, I am not advocating exposing a .species sysvar.   Thus unless you are certain the bot you are looking at is of the same species you are - like say you just gave birth to it - comparisons of subspecies numbers tell you nothing.   In particular, a .subspecies sysvar, should we decide to expose it, would not help you determine whether a bot you were looking at was of the same species you are....

[Numsgil]

I don't mind the memloc/memval pair, because they can be considered a pseudoaggressive attack (thinking on it now, we might want to consider some sort of countermeasure).  Most of the other refvars that give information about a bot that shouldn't be immediately visible I'm not too crazy about.  The beauty of memloc is that you have to pick a single memory location to scan per cycle.

Note, however, that not all of the information stored about a bot in its VB struct should necessarily be visible to anyone in the sim.  Number of generations, for instance.  Theoretically the bots placed in a sim aren't the first of their kind.  They've been picked up from some other environment, and have their own implicit life histories.

I'm also leaning towards DNA being unreferencable within the sim.  The idea being that the seperation between phenotype and genotype is important in the grand scheme of things.

And last, mutations can be considered errors in the DNA copy mechanisms, meaning that the DNA copy mechanism copied in good faith but wasn't perfect.  We keep track of them because its useful metadata when examining DNA.  To the bot, though, if it knew about the mutations it would have fixed them.

The exception to this would probably be .mrepro.  In theory a bot could "mark" a child as a mutant when it mrepros, since it knows it's producing a mutant baby.  Though I can't see this as a general enough use to really warrant a sysvar, you can see my line of reasoning.

I'd be in favor of dropping xpos, ypos, and maxvel if not for compatibility issues with some older bots.  In fact, I think even local versions of xpos and ypos should be dropped in favor of a polar system-- give an angle to a target and an estimated distance.  That way you can drop the dist and angle operators, which are a huge pain to look at in evolved DNA.

[Jez]

Remember, a bot's subspecies number is species relative.

Thankyou for the correction, I'm still not in favour of exposing it though!  

[EricL]

I don't mind the memloc/memval pair, because they can be considered a pseudoaggressive attack (thinking on it now, we might want to consider some sort of countermeasure).  Most of the other refvars that give information about a bot that shouldn't be immediately visible I'm not too crazy about.  The beauty of memloc is that you have to pick a single memory location to scan per cycle.

Agreed.  Refvars are.... inelegant.  I dislike the sysvar space they consume and the total overlap between the view and tie sysvars.  We are so obsessed with being able to do things in a single cycle, but seemingly atomic complex actions are going to require multiple cycles to accomplish, perhaps many cycles.

Note, however, that not all of the information stored about a bot in its VB struct should necessarily be visible to anyone in the sim.  Number of generations, for instance.  Theoretically the bots placed in a sim aren't the first of their kind.  They've been picked up from some other environment, and have their own implicit life histories.

I won't argue this one and will even agree given the current DB design which in particular, uses simualted phsyical morphs..

I'm also leaning towards DNA being unreferencable within the sim.  The idea being that the seperation between phenotype and genotype is important in the grand scheme of things.

So, here I will at least postulate a different position and direction.  I need to write up a larger topic on this, but here is the gist.  I know you said DNA shoudl be unreferenceable and not mem arrays, but at the extreme, if our phenotypes are solely simualted physical morphs, then we will be forever constrianed by the collison detection scalability problem.  The achilles heel of Alife is the requirement to write code in the simulator to enable every morph-morph interaction.  In such a system, bots can never evolve beyond what the code in the simulator allows them.  On the otherhand, the closer our phenotypes and the environment are to the "native" environment (I.e. native machine code running on or even within/instead of the OS) the fewer interactions need to be anticipated and coded.  It becomes an open system.  We need not code for collision detection (term used here an a moniker for all interactions) it just happens.  At an extreme, there is no simulator and the bots are exes running wild!!!

Now, I know we have had this conversation before and I know this is mostly pie in the sky dreaming on my part, so please everyone, don't flame me just yet.  I realize it would be a serious departure and we would lose much of the DB audience and also much of what DB is about so I am not really seriously advocating this, bit what I am saying is that making DNA (and more importantly, the mem array and yes, I know you didn't say this) inacessable is going in the wrong direction.  If anything, we should facilitate more direct interactions between the mem arrays and DNA of different bots - interactions on a non-physical plane of existance. I think of the mem arrays as the real phenotypes and the setting of local private vars and sysvars such as eyewidth as the beginning of morphogenesis.  State values in the memory are the morph.  This is totally off the top, but maybe something in parallel to the physical world like placing all the mem arrays in a single address space and adding commands which operate in that space.  Peek. Poke. Copy, Move, etc.  Mutations could be linked directly to the "physical" act of duplicating DNA in this space.   Locality in the phsycal world might reflect locality in the address space or vice versa.  A bot's sim reality becomes merely a shadowy reflection of their true virtual self....  (man, I've seen The Matrix too many times)  A bot could even "ascend" into the pure virtual space with no phsycial morph.  (Okay, now too much Stargate.  My apologies...)

Anyway, my high level point is that interactions between chunks of memory is what CPUs are good at and I would venture enabling more of that would allow us to start seeing adaptations based upon interactions which no human had to enable aprioi.  But that said, I really don't know how to do that in combination with the DB spirit and our simualted phsycaility.  Perhaps its just too different a paradym.

And last, mutations can be considered errors in the DNA copy mechanisms, meaning that the DNA copy mechanism copied in good faith but wasn't perfect.  We keep track of them because its useful metadata when examining DNA.  To the bot, though, if it knew about the mutations it would have fixed them.

The exception to this would probably be .mrepro.  In theory a bot could "mark" a child as a mutant when it mrepros, since it knows it's producing a mutant baby.  Though I can't see this as a general enough use to really warrant a sysvar, you can see my line of reasoning.

Absolutely.  As above, I would favor a move towards sytem where mutations were grounded in and a side effects of a more "natural" albeit imperfect virtualized phsycial copying processes.

I'd be in favor of dropping xpos, ypos, and maxvel if not for compatibility issues with some older bots.  In fact, I think even local versions of xpos and ypos should be dropped in favor of a polar system-- give an angle to a target and an estimated distance.  That way you can drop the dist and angle operators, which are a huge pain to look at in evolved DNA.

Agreed.  I would go even further and say vision should be used to replace this.  We have dist and angle today for the most part and I've been toying with the idea of havign the ability to switch vision into a mode where eye values represent occlusion percentage, not bot nearness.  Something along that line would make it even harder for bots and require more bot logic but woudl be mor epowerful itn eh end (bots could look past things. etc.)

[EricL]

Remember, a bot's subspecies number is species relative.

Thankyou for the correction, I'm still not in favour of exposing it though!  

Worry not.  I think we have established the fact that people don't want it and so I don't plan to expose it.

I still don't think it's the cheat you all think it is.  It does not help in species recognition and the only real cheat I see (other than killing your own mutant children or conspecs, which itself is an adaptation which could be selected for or against) is for detecting virus infection in conspecs in a sim with no mutaitons, such as in the leauges, where we could disable it.   But... I yield to the consensus.

I do plan to use it internally someday to enable the disaply of phylogenic trees.  I assume no one will object to that.

[Endy]

Could we sim how real animals figure out distances between points? I've heard some can actually sense magnetic north, could something similar be done?

Some globals like sun should be left in, maybe even improved to indicate amount of light/time remaining until dark. Could use some semi-global variables to simulate sound or gradient concentrations.

Might be an idea to spin off a seperate version that relies on pure code instead of simulated physical interactions. Still needs some way for us humans to have an idea about what is going on. Need to have a somewhat complex enviroment that would encourage interspecies interactions and allow multiple organisms simultaneously. Would love to see it done right, just not sure how it'd be done.

Edit:

Could Mass be used instead of maxvel? Not sure how the two correlate, but it's more realistic for bots to know their own and others speed restrictions based on size than maxvel.

[EricL]

We have to be careful about the word "global".  The objection I beleive is not necessarily to sysvars which provide information about things at global scale but rather to sysvars which violate the principle of locality.

Xpos and ypos violate the principle (although .ypos does not in pond mode sims) because given our choice to simuate a 2d world which corrpsonds largely to our own physcial environment and the physics thereof, there is no conceivable sense that could provide absolute poisitioning info to a bot on a field of arbitrarily large size short of them inventing GPS satilites.  (.ypos makes senss in pond mode if you assume bots can sense pressure and thus depth.)

Things like sun and cycles left before sunset or sunrise on the otherhand (or a magnetic North sense)- do not in my opinion violate the principle since it is quite concievable that given the implied principles of our simulated world, a bot could sense whether it is day or night or what the angle of the sun is in the sky.   (Of course, this begs the question as to whether our simulated physicality simulates a planet that rotates as opposed to light bulb that mearly turns on and off, as is the case today.   I say that the sun mearly turns on and off today and does not "move" because of the .sun (400) sysvar which today turns to 1 if .aim is within .18 radians of looking at the sun, which is assumed to be straight overhead and not to move - but I digress.)

Maxvel similarily violates the principle because it is an absolute rule of the physics of the world, info that IMHO bots should not be magically informed of - they should have to figure out.

A bot's mass does not tell it anything about the max velocity the sim allows.  It does help the bot figure out the relationship between movement force and their own acceleration (which can also be impacted by fluid resistance and friction) but not the ultimate speed limit the sim allows.

[Numsgil]

One of the changes I made in the C++ version was to the sun sysvar.  It would detect the strength of sunlight, instead of just a yes/no.  I also tied in the idea of sun to non-pond mode sims, where *.sun would return how much nrg/cycle a veg got (or how much nrg/kilobody,or whatever, depending on the mode).

.Sun right now is strictly yes/no, so it's wide open to improvements in what information it returns.

[Endy]

Isn't there a cap on how much nrg the bots can spend on accelerating anyways?(ie. no more than maxvel) So should it just be scrapped in future versions, since it provides little useful information? Why not just bring speed more in line with the actual equation? Then 32000 nrg converted into acceleration would still only move a bot at whatever we decide the highest allowable speed is.

Sounds like that'd be cool for sun since it'd be more realistic. Would a SunAngle sysvar be useful? Bots could roughly navigate with it.

I think "globals" would be okay just as long as they're read only like sun is. It's kind of oddball that we have some of the same limits on instantaneous communication ourselves. Makes me wonder sometimes.

[EricL]

Isn't there a cap on how much nrg the bots can spend on accelerating anyways?

Yes there is a cap.  Briefly, if the sum of the bot's voluntary force vectors would result in a velocity exceeding the max velocity of the sim (the resulting velocity is a function of the bot's mass) or the nrg the bot is attempting to spend on voluntary movement that cycle exceeds 100, then the nrg spend is capped at either the amount of nrg needed to acheive the maxvel or 100, whichever is lower and the resulting velocity due to voluntary movement is set to maxvel in the first case, or whatever 100 nrg gets you in the second.

Note that the bot's actual resulting velocity is a function of all forces acting on the bot, not just it's own movement.  This includes but is not limited to gravity, collision forces with bots or shapes or the world edge, tie torque forces, drag due to friction and fluid resistance, bouyancy, brownian motion, planet eaters and tie drag forces.  Note that there is no cap on the resulting vector sum of these velocities.  In particular, it may exceed maxvel.  (A crafty bot builder could use this to advantage in the leagues I.e. torque provided via a  stiff tie could fling a bot at faster than maxvel...)

(ie. no more than maxvel) So should it just be scrapped in future versions?

Yes, I beleive the .maxvel sysvar should be removed.   There should still be a human settable maxvel for the sim, but it should not be exposed to bots via a sysvar.