http://www.technologyreview.com/view/511846/an-autopsy-of-a-dead-social-network/
The above is an interesting post-mortem of Freindster which illustrates some of the emergent nature of social movements. Its interesting to see the conclusions that the researchers reached about the resiliance of the network. This echos some of the resiliance models I have seen recently surrounding the issues of bullying, where children and teens who have small peer networks and mentor networks are much less resiliant to bullying.
It raises the question about whether a student is able to be identified as being "vulnerable" to bullying simply by examining their social network and an intervention designed to mitigate the risk or better understand the underlying issues that have contributed to the social isolation of that student. ( I would suggest that the systemic removal of all possible mentors from the school environments means that students are having their social networks composed of other students who are by their very nature not as mature or rich in experience as adult mentors could be, which results in the student having access to lower quality mentor networks).
Showing posts with label Emergent systems. Show all posts
Showing posts with label Emergent systems. Show all posts
Monday, March 11, 2013
Thursday, April 5, 2012
Thought experiments for Automated Starcraft Players
http://graphics.stanford.edu/~mdfisher/GameAIs.html
Starcraft 2 Automated Player
This is a brilliant writeup of both the architecture and some of the issues to consider when building an automated player for a game.
There are so many little bits of wisdom in this article that I want to spend time thinking about and hacking on.
First thoughts.
Interesting AI architecture. It (if I read it correctly) seems to use a kind of switched swarm intelligence for some of the decision making. Which makes sense when you consider the intricacy of trying to build a single unified decision making engine that could handle all the different individual units, their micro objectives and integrate that into a macro plan. (I would do that for a Phd with bells on...) kind of skynet for Starcraft....
The emergent strategies that have been implemented to deal with chaotic and imprecise events within the environment are interesting. Kind of obvious now its been pointed out. Again this moves a solution more toward a swam model where each agent/thread/program/entity deals with a small part of the map or a small objective as opposed to a large monolithic algorithm that would be a monster to debug. The tradeoff being that each of these small programs has loose coupling with all the others. They cannot share their internal micro state and need to implement some form of inter-entity communication if they need to cooperate. Which gets us back to resource competition, group decision making and all the other fun of peer agent models.
It's interesting to note that there are some higher level constructs in the architecture that are delegated to task switching and managing the stream of data comming in about the game state. Currently these are very single purpose; making debugging much simpler. But another task could be developed to run above the agents to implement a coordinating role and implement the "master plan" for the play session. (yet another Phd...)
The mirror driver implements the equivilent of a "sense" mechanism. We could describe it as "sight", but it does not share the same type of information stream as we understand "sight" in a biological form. Still its a fairly wide channel of information that is then internalised and used to generate a state represenation of the AI's environmental reality.
This state represeation will also include (expliclty or implicitly) some encoded knowledge about the artifacts in that environment. The number of different possible states that each individual artifact can exist in, the inter-artifact relationships, communications and inter-actions etc. It would be an interesting datascape to look at (yet another Phd...)
Dealing with the scene perception and understanding is interesting. It would be fun to offload this information to a different processor(or network) and see exactly how rich an internal representation could be generated from the information stream.
Dealing with the chaotic nature of the interaction with the opposing player, the state changes of the particular units and the static and dynamic elements of the environment is an interesting set of problems. (Called housekeeping in the article) Which again would generate an interesting set of rules and emergent behaviours in a good learning system.
It would be an interesting exercise to run a few hundred games on the same map and build up an understanding of the potential of each map. This may be an effective mechanism for debugging maps. Both the functional level debugging( finding holes and bugs ) and the logical debugging (balancing, removing or adding choke points, tuning difficulty etc). This is something I have been wanting to do for Chess for a while, is to calculate the true value of every square on the board. Probably someone has already done it... I just want to do it in as a multi-dimensional analysis, to see how many hidden variables I can tie to simple positional space, then to particular pieces and finally to particular strategic choices. Since there are only 32 peices, it should not take too long. Just have to raid a couple of databases for some game records. (yet another Phd...)
There is a fun little element mentioned called "Personas" which seems to be an undeveloped mechanism to mess with opponent players minds during the game. Its a simple blind system that uses a strategy of tying complex chat sentences during play....
Not sure who effective this would be but its an interesting strategic possibility. Attack the players outside the game environment.
Using a console overlay seems to be cute but wasteful. I would build a whole seperate GUI for monitoring the AI. (Benefit of multiple monitors I guess. )
At the end of the day, this is a great framework to build on, but seems to consist of a lot of fairly hard coded routines and strategies that are played out by a quite rigid system. Yes its fast, yes its beyond human capacity... but I don't feel like its moving beyond being a very complex script. I want to see my artifical children grow beyond my capacity.... not just leaverage hardward speed as a blunt instrument.
Starcraft 2 Automated Player
This is a brilliant writeup of both the architecture and some of the issues to consider when building an automated player for a game.
There are so many little bits of wisdom in this article that I want to spend time thinking about and hacking on.
First thoughts.
Interesting AI architecture. It (if I read it correctly) seems to use a kind of switched swarm intelligence for some of the decision making. Which makes sense when you consider the intricacy of trying to build a single unified decision making engine that could handle all the different individual units, their micro objectives and integrate that into a macro plan. (I would do that for a Phd with bells on...) kind of skynet for Starcraft....
The emergent strategies that have been implemented to deal with chaotic and imprecise events within the environment are interesting. Kind of obvious now its been pointed out. Again this moves a solution more toward a swam model where each agent/thread/program/entity deals with a small part of the map or a small objective as opposed to a large monolithic algorithm that would be a monster to debug. The tradeoff being that each of these small programs has loose coupling with all the others. They cannot share their internal micro state and need to implement some form of inter-entity communication if they need to cooperate. Which gets us back to resource competition, group decision making and all the other fun of peer agent models.
It's interesting to note that there are some higher level constructs in the architecture that are delegated to task switching and managing the stream of data comming in about the game state. Currently these are very single purpose; making debugging much simpler. But another task could be developed to run above the agents to implement a coordinating role and implement the "master plan" for the play session. (yet another Phd...)
The mirror driver implements the equivilent of a "sense" mechanism. We could describe it as "sight", but it does not share the same type of information stream as we understand "sight" in a biological form. Still its a fairly wide channel of information that is then internalised and used to generate a state represenation of the AI's environmental reality.
This state represeation will also include (expliclty or implicitly) some encoded knowledge about the artifacts in that environment. The number of different possible states that each individual artifact can exist in, the inter-artifact relationships, communications and inter-actions etc. It would be an interesting datascape to look at (yet another Phd...)
Dealing with the scene perception and understanding is interesting. It would be fun to offload this information to a different processor(or network) and see exactly how rich an internal representation could be generated from the information stream.
Dealing with the chaotic nature of the interaction with the opposing player, the state changes of the particular units and the static and dynamic elements of the environment is an interesting set of problems. (Called housekeeping in the article) Which again would generate an interesting set of rules and emergent behaviours in a good learning system.
It would be an interesting exercise to run a few hundred games on the same map and build up an understanding of the potential of each map. This may be an effective mechanism for debugging maps. Both the functional level debugging( finding holes and bugs ) and the logical debugging (balancing, removing or adding choke points, tuning difficulty etc). This is something I have been wanting to do for Chess for a while, is to calculate the true value of every square on the board. Probably someone has already done it... I just want to do it in as a multi-dimensional analysis, to see how many hidden variables I can tie to simple positional space, then to particular pieces and finally to particular strategic choices. Since there are only 32 peices, it should not take too long. Just have to raid a couple of databases for some game records. (yet another Phd...)
There is a fun little element mentioned called "Personas" which seems to be an undeveloped mechanism to mess with opponent players minds during the game. Its a simple blind system that uses a strategy of tying complex chat sentences during play....
Not sure who effective this would be but its an interesting strategic possibility. Attack the players outside the game environment.
Using a console overlay seems to be cute but wasteful. I would build a whole seperate GUI for monitoring the AI. (Benefit of multiple monitors I guess. )
At the end of the day, this is a great framework to build on, but seems to consist of a lot of fairly hard coded routines and strategies that are played out by a quite rigid system. Yes its fast, yes its beyond human capacity... but I don't feel like its moving beyond being a very complex script. I want to see my artifical children grow beyond my capacity.... not just leaverage hardward speed as a blunt instrument.
Tuesday, April 3, 2012
Emergent intelligent behaviour in the hive
http://www.scientificamerican.com/article.cfm?id=you-have-a-hive-mind
This is an interesting article on decision making in the bee hive.
The interesting aspects are both the mechanism and the result.
The mechanism of using inhibition to prevent deadlock is quite useful and I will play with it later.
The result however is even more interesting. In the article they talk about the two groups of bee scounts returning from scouting and starting to recruit undecided individiuals.
If we assume that both scouting parties found suitable locations ( they were not unsuitable ) the question is if there is any mechanism to select between locations based on the quality of the locations or are they simply randomly deciding between locations that all exceed some minimum specification ( dry, enclosed, no bears?)
I would assume that a bee scout can only report on a single location at a time. So, I would assume that if a scout is out looking, it will stop looking as soon as it finds a location that meets minimum spec. As there is no point keeping looking as it would then be making the decision of which was the location most worth reporting.
Another factor is distance, it makes sense that two scouting parties depart at the same time and the one who finds the first viable location would return first. Thus they to recruit other individuals for a time period until the second party returns. I would guess that this may be a factor and would favor moving the hive a short distance rather than a long distance.
Another bit of information that may play out is the strength of the scouts dance. If the scout is not feeling good about the location... they perhaps will not fully invest in their dance and so may be easier to inhibit. This may be influenced by the stress levels of the scout. If they find a location and its a bit crappy and some of their fellow scouts get eaten... would they still dance as strongly?
If you think about that, the undecided individual has to make a decision. Is what the scout tells me a better option than what I already know ( status quo)? Is what this scout tells me better than what another scout has already told me? (They can only get one lot of information at a time) Or is this better than what another scout may tell me in the future?
So there are still lots of aspects of the decision making process that are not clarified by this article. It just describes an anti-deadlock mechanism for group decision making.
This is an interesting article on decision making in the bee hive.
The interesting aspects are both the mechanism and the result.
The mechanism of using inhibition to prevent deadlock is quite useful and I will play with it later.
The result however is even more interesting. In the article they talk about the two groups of bee scounts returning from scouting and starting to recruit undecided individiuals.
If we assume that both scouting parties found suitable locations ( they were not unsuitable ) the question is if there is any mechanism to select between locations based on the quality of the locations or are they simply randomly deciding between locations that all exceed some minimum specification ( dry, enclosed, no bears?)
I would assume that a bee scout can only report on a single location at a time. So, I would assume that if a scout is out looking, it will stop looking as soon as it finds a location that meets minimum spec. As there is no point keeping looking as it would then be making the decision of which was the location most worth reporting.
Another factor is distance, it makes sense that two scouting parties depart at the same time and the one who finds the first viable location would return first. Thus they to recruit other individuals for a time period until the second party returns. I would guess that this may be a factor and would favor moving the hive a short distance rather than a long distance.
Another bit of information that may play out is the strength of the scouts dance. If the scout is not feeling good about the location... they perhaps will not fully invest in their dance and so may be easier to inhibit. This may be influenced by the stress levels of the scout. If they find a location and its a bit crappy and some of their fellow scouts get eaten... would they still dance as strongly?
If you think about that, the undecided individual has to make a decision. Is what the scout tells me a better option than what I already know ( status quo)? Is what this scout tells me better than what another scout has already told me? (They can only get one lot of information at a time) Or is this better than what another scout may tell me in the future?
So there are still lots of aspects of the decision making process that are not clarified by this article. It just describes an anti-deadlock mechanism for group decision making.
Monday, March 26, 2012
Slug bot
http://www.ias.uwe.ac.uk/Robots/slugbot.htm
This is an interesting application of robotics with the addition of behavioural rules and a basic ecconomy model to try to generate an emergent behaviour set.
Just got to hope that the little buggers can't learn. Otherwise they might start putting anything they like into the digester... think Cane Toads... but with wheels.
This is an interesting application of robotics with the addition of behavioural rules and a basic ecconomy model to try to generate an emergent behaviour set.
Just got to hope that the little buggers can't learn. Otherwise they might start putting anything they like into the digester... think Cane Toads... but with wheels.
Thursday, March 22, 2012
Emergent behaviour in the cloud
http://www.technologyreview.com/blog/arxiv/27642/
This is an interesting article hypothesising possible disater in the cloud computing systems due to the same sorts of systemic interactions that are observable in other computer or biological systems.
The scenario they illustrate is fun and plausible. However its also a little "simple". Its simply two coupled osscilators. (or a double pendulm in the simplest terms) with effectivly an unlimited power input which creates a growth spiral that will only stop when it hits some limit in the system... either causing a crash or some other effect on the system function or the osscilation.
Does make me wonder how many of these emergent effects are actually already going on in the software I write. There are always weird fragments of behaviour that can be observed... but are not focused on until they show overt negative effects (bugs). Until then they are just ... weirdness. Some of it is the interplay of frameworks and code that is outside my control or undocumented or simply to low in the stack to bother with.
Other bits are loops and event chains that have unexplored outcomes... these however I take responsibility for. Code coverage and unit testing are mechanisms to try to tame these. However Unit testing is really looking at the end result rather than the process. If something bounces around wildly under the bonet but still generates the correct response... a unit test is still happy.
I think in my head atleast, I still think of the computer as a deterministic system.... which is just wrong. Even looking at a simple little GUI app its obvious that its an infinitly dynamic system. Its closer to a set of springs and dampers than it is to a deterministic ratchet.
While unit tests let us sample outcomes at the interfaces ( this is a good thing), it does tend to accept the fact that whats inside the interface box is .."unknown"... The question is what can we do to systematically peer into that dark space?
Endless logging calls?
Create manual tracing stacks?
Use a mad monkey testing engine to generate input with some sort of code coverage system to watch the results and look for some rule violations?
There are lots of possibilities for detecting "weird" behaviour in dynamic systems. Kind of like load tuning a web app but with a lot more variables. At some point assumptions get made and may not be upheld under different circumstances.
The complexity guys probably have some ideas but I would guess that even they do some level of decomposition and division simply to manage the exponential effect of multiple variables and their possible intereactions.
I think the main issue is to reduce the complexity in the system. Intruduce buffers and dampers to regulate the flow. Prevent race conditions and resource contention, even when it places a ceiling on performance. Implement static limits even when they are a bit arbitrary. At least there is a limit in place that can be tuned if it get hit.
This reminds me of the issue with the oracle databases in a previous post. They had hard limits that made sense in the context of stand alone servers, but when they interacted in a networked environment, the synchronising mechanism had both emergent properties as well as presenting a possible exploit for inducing behaviour (crashes).
The problem there was the tight coupling of the index numbers between the database instances. By introducing loose coupling with a buffer structure that allowed the coupling to happen but did not kill the databases if it went rogue, the tightly coupled system becomes much less fragile. Problems cannot automatically propogate through the network of databasea and kill them all. Obviously there would need to be some watch put on the buffers and clear exception rules in place ( which are also probably able to be attacked if a flaw is found....) which then allow the whole dynamic system to be monitored.
I guess the bigges need is to be willing to allow one toxic database to fail without the failure propogating to others in the network. This is, I think the assumption that needs to be explicitly dealt with in the case of this cloud scenario.
The problem is that if one set of servers goes down and the load shifts unpredictably, then it could cause a cascading failure as more and more load gets shifted around and more things fail. These types of cascade events are only stopped by firewalls. The concept is that a fire can burn on one side of the wall, but cannot cross the wall. In server terms, that may mean that a server cannot accept more load than it has capacity to handle, no matter how much load is trying to be shifted onto it.
There also needs to be a plan for graceful failure. Servers need to go down on their knees before they go down on their faces. (While they are on their knees, they write the load out to disk and then die gracefully....)
Anyway... enough rambling.
This is an interesting article hypothesising possible disater in the cloud computing systems due to the same sorts of systemic interactions that are observable in other computer or biological systems.
The scenario they illustrate is fun and plausible. However its also a little "simple". Its simply two coupled osscilators. (or a double pendulm in the simplest terms) with effectivly an unlimited power input which creates a growth spiral that will only stop when it hits some limit in the system... either causing a crash or some other effect on the system function or the osscilation.
Does make me wonder how many of these emergent effects are actually already going on in the software I write. There are always weird fragments of behaviour that can be observed... but are not focused on until they show overt negative effects (bugs). Until then they are just ... weirdness. Some of it is the interplay of frameworks and code that is outside my control or undocumented or simply to low in the stack to bother with.
Other bits are loops and event chains that have unexplored outcomes... these however I take responsibility for. Code coverage and unit testing are mechanisms to try to tame these. However Unit testing is really looking at the end result rather than the process. If something bounces around wildly under the bonet but still generates the correct response... a unit test is still happy.
I think in my head atleast, I still think of the computer as a deterministic system.... which is just wrong. Even looking at a simple little GUI app its obvious that its an infinitly dynamic system. Its closer to a set of springs and dampers than it is to a deterministic ratchet.
While unit tests let us sample outcomes at the interfaces ( this is a good thing), it does tend to accept the fact that whats inside the interface box is .."unknown"... The question is what can we do to systematically peer into that dark space?
Endless logging calls?
Create manual tracing stacks?
Use a mad monkey testing engine to generate input with some sort of code coverage system to watch the results and look for some rule violations?
There are lots of possibilities for detecting "weird" behaviour in dynamic systems. Kind of like load tuning a web app but with a lot more variables. At some point assumptions get made and may not be upheld under different circumstances.
The complexity guys probably have some ideas but I would guess that even they do some level of decomposition and division simply to manage the exponential effect of multiple variables and their possible intereactions.
I think the main issue is to reduce the complexity in the system. Intruduce buffers and dampers to regulate the flow. Prevent race conditions and resource contention, even when it places a ceiling on performance. Implement static limits even when they are a bit arbitrary. At least there is a limit in place that can be tuned if it get hit.
This reminds me of the issue with the oracle databases in a previous post. They had hard limits that made sense in the context of stand alone servers, but when they interacted in a networked environment, the synchronising mechanism had both emergent properties as well as presenting a possible exploit for inducing behaviour (crashes).
The problem there was the tight coupling of the index numbers between the database instances. By introducing loose coupling with a buffer structure that allowed the coupling to happen but did not kill the databases if it went rogue, the tightly coupled system becomes much less fragile. Problems cannot automatically propogate through the network of databasea and kill them all. Obviously there would need to be some watch put on the buffers and clear exception rules in place ( which are also probably able to be attacked if a flaw is found....) which then allow the whole dynamic system to be monitored.
I guess the bigges need is to be willing to allow one toxic database to fail without the failure propogating to others in the network. This is, I think the assumption that needs to be explicitly dealt with in the case of this cloud scenario.
The problem is that if one set of servers goes down and the load shifts unpredictably, then it could cause a cascading failure as more and more load gets shifted around and more things fail. These types of cascade events are only stopped by firewalls. The concept is that a fire can burn on one side of the wall, but cannot cross the wall. In server terms, that may mean that a server cannot accept more load than it has capacity to handle, no matter how much load is trying to be shifted onto it.
There also needs to be a plan for graceful failure. Servers need to go down on their knees before they go down on their faces. (While they are on their knees, they write the load out to disk and then die gracefully....)
Anyway... enough rambling.
Tuesday, December 6, 2011
Wired Bitcoin article
http://www.wired.com/magazine/2011/11/mf_bitcoin/all/1
Really interesting post on the internals of both the Bitcoin community and the emergent structure of the economy they constructed.
Really interesting post on the internals of both the Bitcoin community and the emergent structure of the economy they constructed.
Emergent structure in volunteer organisations
http://daggle.com/closed-unfriendly-world-wikipedia-2853
This is another sneak peak into an evolving organisation. The post itself is a fun read but the indirect references in the comments lead to better snippits of corruption and trust.
This kind of emergent structure and rules systems (that then get ignored) is fascinating. Especially if you think about how under siege some Wikipedia articles must be. Being able to generate a self assembling organisation that can collate and maintain some semblance of structure is amasing.
The aggregation and politicking over the "rules" suggests some interesting mechanisms at play. Issues like, trust (that the rules are valid/correct/followed), faith that the rules are coherent and unambiguous, and the embedding within the rules of the domain langauge of accronyms and community dialects.
It would be a fascinating community to study.
This is another sneak peak into an evolving organisation. The post itself is a fun read but the indirect references in the comments lead to better snippits of corruption and trust.
This kind of emergent structure and rules systems (that then get ignored) is fascinating. Especially if you think about how under siege some Wikipedia articles must be. Being able to generate a self assembling organisation that can collate and maintain some semblance of structure is amasing.
The aggregation and politicking over the "rules" suggests some interesting mechanisms at play. Issues like, trust (that the rules are valid/correct/followed), faith that the rules are coherent and unambiguous, and the embedding within the rules of the domain langauge of accronyms and community dialects.
It would be a fascinating community to study.
Subscribe to:
Posts (Atom)