Code center > Suggestions
Would a *.subspecies sysvar be facist?
EricL:
--- Quote from: Jez ---.subspecies devalues all the recognition systems for a start.
--- End quote ---
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:
--- Quote from: EricL ---Remember, a bot's subspecies number is species relative.
--- End quote ---
Thankyou for the correction, I'm still not in favour of exposing it though!
EricL:
--- Quote from: 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.
--- End quote ---
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.
--- Quote from: Numsgil ---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.
--- End quote ---
I won't argue this one and will even agree given the current DB design which in particular, uses simualted phsyical morphs..
--- Quote from: Numsgil ---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.
--- End quote ---
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.
--- Quote from: Numsgil ---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.
--- End quote ---
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.
--- Quote from: Numsgil ---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.
--- End quote ---
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:
--- Quote from: Jez ---
--- Quote from: EricL ---Remember, a bot's subspecies number is species relative.
--- End quote ---
Thankyou for the correction, I'm still not in favour of exposing it though!
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version