Wednesday, November 28, 2012
Rules for Art Nouveau
I like figuring out algorithmic rules for particular genre's of art and architecture.
Art Nouveau - This was a style that arose as a reaction to Academic Art. If you wish to understand why Art Nouveau seems to break so many rules (while still providing evidence of being fully aware of them) have a look at how rigorously the rules were emphasised in Academic Art. Think of Academic Art as a "Street Art" style that arose from Academy trained artists wanting to express themselves differently but not being able to forget all the rules they had already learned.
So my "rules" for Art Nouveau are:
2.5 dimensions. This means that the image is composed of discreet "layers" which do not obey the same coherent rules of persective or foreshortening. Each Layer can include these elements but they are not "simulating" depth. Z order is essential but needs to be "played" with to create a wholeistic composition.
Establish borders and framing then break it. One of the essential elements in this style is the breaking of the frame. This creates the entertaining "flow" between the layers and binds the whole image together.
Use frames and borders to "punch through" and combine layers. This technique also creates links betwen the layers and creates relationships. This compensates for the lack of relationships that would otherwise be created by the rules of depth and helps with the Mise-en-scene of the content elements.
Contrast between geometric repetition and organic repetition. These should be similar scale to help re-inforce the juxtaposition of the two different styles. For example the conrtast between a repeating geomtric motif and a group of flowers or butterflies.
Similarity rather than symetry. Elements are often "similar" in that they occupy symetrical areas on the composition but are not "mirror" images. This plays with the concept of geomtric symetry, showing that the artist is aware of the rules but has chosen to be "playful" with them.
Dynamic lines work and outlines. The hand inked style of the line work and the heavy outline styles are characteristic of the materials and the media that the early work was build with. This has come to be part of the "signature" of the graphic design work. (Obviously not a factor in the Architectural works)
Curves. The convention of never quite having a straight line is one of those rule-of-thumb that the artists "play" with. I think its the contrast between the curves and the lines that make for the playful nature while still being "constrained". The curves tend to be flowing lines and "spline" type curves rather than crazy scribble type lines. They are very dynamic and directed.
Content. The style draws in and often contrasts geomtric motifs and styalised nature. Figures and objects are often posed together with the figures being displayed in "static" poses with dynamic elements such as hair and drapes shown blowing styalistically in the breeze.
Shading and textures. The use of flat colour to create obviously simple shading and "hand painted" style shading contrasts with true shaded gradients creates an interesting juxtaposition of textures. This can be a subtle effect. Generally each layer has its own "style" of shading which is consistent through the layer. Soft washes and out of focus forms are often layered in the background.
Thursday, November 22, 2012
Neural Plasticity and Brain Training Resources collection
http://en.wikipedia.org/wiki/Neuroplasticity
http://www.normandoidge.com/normandoidge.com/MAIN.html
One case study that I have not seen clearly connected to the topic of Neural Plasticity is that of the London Cab drivers.
London Cabbies undergo a legendary training that involves memorising huge amounts of map data and street names. I remember someone in an interview on tv once saying that someone had used MRI to show that there were changes in the drivers brains after this training process was complete. Tada! NP at work.
Brain Fitness (Limit to systems that have some lonitudinal data collection and analysis function, not just games that exercise the brain)
http://www.brainmetrix.com/
http://www.lumosity.com
http://www.braintraining101.com/
http://www.cognifit.com
http://www.actibrain.com/
http://www.neuronation.com/
http://www.positscience.com/
http://www.happy-neuron.com/
http://www.fitbrains.com/
http://www.brainarena.com/
http://www.brainbashers.com/braintraining.asp
Clinical ???
http://www.scientificbraintrainingpro.com/
http://advancedbrain.com/brainbuilder/brainbuilder.html
http://www.braindepartment.com/pages/for-organisations
Pro
http://www.abc.net.au/health/talkinghealth/factbuster/stories/2012/09/25/3597591.htm
http://www.sharpbrains.com/executive-summary/
Con
http://www.abc.net.au/news/2010-04-21/uk-research-casts-doubt-on-brain-training/404392
http://www.med.unsw.edu.au/psychweb.nsf/resources/Consumer+Information+Sheet+-+Brain+Training.pdf/$file/Consumer+Information+Sheet+-+Brain+Training.pdf
http://blogs.scientificamerican.com/talking-back/2012/09/25/best-evidence-for-brain-training-falls-short/
http://www.smartplanet.com/blog/thinking-tech/q-a-new-evidence-shows-brain-training-games-dont-work/11758
Catholic Schools Trial of the Arrowsmith Program
http://www.theaustralian.com.au/national-affairs/education/brain-training-to-assist-students/story-fn59nlz9-1226484954506
http://theconversation.edu.au/brain-training-or-learning-as-we-like-to-call-it-9951
Other Programs
http://www.braingym.org/
http://www.dore.co.uk/
http://www.movetolearn.com.au/
http://www.braintrain.com/
http://www.learningrx.com/brain-training.htm
News Site
http://www.sharpbrains.com/index.php
Forums
https://groups.google.com/forum/?fromgroups#!forum/brain-training
http://www.normandoidge.com/normandoidge.com/MAIN.html
One case study that I have not seen clearly connected to the topic of Neural Plasticity is that of the London Cab drivers.
London Cabbies undergo a legendary training that involves memorising huge amounts of map data and street names. I remember someone in an interview on tv once saying that someone had used MRI to show that there were changes in the drivers brains after this training process was complete. Tada! NP at work.
Brain Fitness (Limit to systems that have some lonitudinal data collection and analysis function, not just games that exercise the brain)
http://www.brainmetrix.com/
http://www.lumosity.com
http://www.braintraining101.com/
http://www.cognifit.com
http://www.actibrain.com/
http://www.neuronation.com/
http://www.positscience.com/
http://www.happy-neuron.com/
http://www.fitbrains.com/
http://www.brainarena.com/
http://www.brainbashers.com/braintraining.asp
Clinical ???
http://www.scientificbraintrainingpro.com/
http://advancedbrain.com/brainbuilder/brainbuilder.html
http://www.braindepartment.com/pages/for-organisations
Pro
http://www.abc.net.au/health/talkinghealth/factbuster/stories/2012/09/25/3597591.htm
http://www.sharpbrains.com/executive-summary/
Con
http://www.abc.net.au/news/2010-04-21/uk-research-casts-doubt-on-brain-training/404392
http://www.med.unsw.edu.au/psychweb.nsf/resources/Consumer+Information+Sheet+-+Brain+Training.pdf/$file/Consumer+Information+Sheet+-+Brain+Training.pdf
http://blogs.scientificamerican.com/talking-back/2012/09/25/best-evidence-for-brain-training-falls-short/
http://www.smartplanet.com/blog/thinking-tech/q-a-new-evidence-shows-brain-training-games-dont-work/11758
Catholic Schools Trial of the Arrowsmith Program
http://www.theaustralian.com.au/national-affairs/education/brain-training-to-assist-students/story-fn59nlz9-1226484954506
http://theconversation.edu.au/brain-training-or-learning-as-we-like-to-call-it-9951
Other Programs
http://www.braingym.org/
http://www.dore.co.uk/
http://www.movetolearn.com.au/
http://www.braintrain.com/
http://www.learningrx.com/brain-training.htm
News Site
http://www.sharpbrains.com/index.php
Forums
https://groups.google.com/forum/?fromgroups#!forum/brain-training
Wednesday, November 21, 2012
Depth of Programming Tools
Being a spectator to the on-going mess that is the microsoft developer roadmap... (would train wreck be too strong?) and reading this post on Rx. It got me thinking about some of the obvious and in-obvious side effects of the endless churn in the Microsoft eccosystem.
* Developers Inability to Commit to a Technolgy
* Third party tools vendors and Extenders lack of commitment
* Consumers lack of clarity on the right technology for their projects
All this is pretty obvious and well blogged about. The thought tha occured to me is that the endless renewal of technologies creates a very "superficial" eccosystem. No-one has the time or the energy to create deep paradigm shifting technologies on top of any of these languages or stacks becase it takes some years of experience and a subtle understanding of the problem space before these kinds of solutions can emerge and be polished.
The above ideas around Rx are drawn from problems with their roots all the way back in the early days of event driven programming, but more recently it draws in concepts from LINQ and other agile data access models. These have all taken time to stew and have been applied to .NET... but now with the maturing of the library .NET has past its prime. It's no longer the kid that is getting all the attention.
Looking at the other Microsoft babies of recent years, SilverLight, XAML, WPF et. al. there has not been enough time for anyone to live with them and start to see solutions to the deep problems. So there is only a superficial set of tools and technologies to work with them... and then they are gone.
I think this becomes a self-reinforcing cycle. Microsoft presents uncertainty and doubt about the tools, developers don't commit to the tools, Microsoft panics and creates new tools with even less certainty and more doubt.
The IT lecturers must be totally pissed off. I remember only a couple of years ago when they finally let go of C++ and upgraded all the courseware to C# and XAML. To have to again totally re-build their course material and test drive it over a couple of years to get it all sorted out will completely piss them off. No wonder book publishers are doing quick and dirty publishing for MS products. There is just no time to get deep with anything.
Anyway, the takeaway is that its the lack of really deep and clever extensions to languages that I feel will be the biggest and most costly loss. These are the tools that provide the biggest bang for their buck and help move whole industries forward. We don't need yet another language or GUI toolkit. We need deep problem solving libraries with thought, well designed API's that have had time and bright minds shape them. We need comprehensive tool chains that are bedded down and have all the subtle features and bugs sorted. This is just not happening on the MS stacks at the moment.
VS2012 is the epitomy of Q&D. There is all sorts of stuff missing or "just" working. It smells of panic. It also smells of trying to put a little something for everyone across a fragmented ecosystem of different technologies. Imagine if all the effort were spent on getting just a few technologies really right. The fact that this has not happened probably points to the fact that any one technology is not a compelling difference anymore. Great support for a language is not a "killer app", so now its good enough to just have "just enough" support to tick the box.
Welcome to the world of increasingly sucky tools from MS.
Monday, November 19, 2012
Unit Testing to find bugs???
http://architects.dzone.com/articles/unit-tests-dont-find-bugs
I just read the above article and a couple of the comments. The author seems to think that Unit Tests have something to do with finding bugs.
What bugs? Unit testing cannot "find" bugs. A developer can use Unit tests to detect violations of expected behaviour (assuming those unit tests exist). Bugs are conceptual issues that may exist in the developesr expected functionality, the users expected functionality, unexpected functionality, future functionality... etc.
1) Unit Tests can be used to verify that a piece of code "does what it is designed to do". I.e, that it has the expected behaviour or functionality as the designer understands it.
2) Unit Tests can't verify that code "does other things that it was not designed to do" as this is an open ended list. Simple design, encapsulation and composition are better tools to manage this kind of complexity.
3) Unit Tests can be used to verify that code "does not do a specific thing that it was designed not to do" but only once the designer/developer knows enough about the undesirable behaviour to write a specific test for it. This then becomes an instance of the first clause above. However, it does not guarantee that this behaviour cannot occur in an unexpected way. It can only verify that the behaviour does not occur in the way expected by the test.
A developer can use a Unit Test to assert something explicitly about the behaviour of a unit of code and then Verify that Assertion now and in the future.
A developer cannot use Unit Tests to infer something about the behaviour of the code. (Well they could, but it will bite them sooner or later)
A Unit Test is an attempt to treat a piece of code as a deterministic machine.
Sample Data In - > Code Under Test -> Expected Behaviour Out.
This system involves no variables. It's a simple mapping from the input to the output. It has no state except what you inflict on it. This is all a Unit Test can be. Even if you get clever and provide an exhaustive list of sample data and run it all through the code, its still the same case. You cannot assert anything about the behaviour of the code except under the conditions you have tested. You can infer about the behaviour of the code under conditions you have not tested... but its guessing. Not even educated guessing. Certainly not SWAG. It's just WAG.
You CANNOT predict all the conditions that the code could, should, might, maybe run under, now or in the future. You can't come close to guessing what tiny modifications might be done to the code... you can't know if that code will be transcoded to another system, language or hardware platform.... it may be compiled, cross-compiled, JIT compiled, interpretted, it might be "optimised" by hand or tool... you code can be so thoughly changed that you can not reason about it. The language standard could evolve, your code could be compiled by better or worse tools, linted, scrubbed, re-ordered, have other code injected, be mutated at runtime, suffer a stack fault, have its memory corrupted.... malware may interfere, API's change, security software not even invented yet may completely stuff it up. Its even possible that your code could run in a Virtual Machine or some other system that allows pause and restart. You code could have its state saved and reloaded or modified and reloaded... or reloaded on a completely different machine in a cluster... or a different data center on a different continent.. there is just nothing that cannot be munged up given the wrong scenario.
But in every case above, you can still assert intended behaviour and verify if the code satisifes that assertion or not.
Just for fun, imagine the worse possible scenario for the piece of code that you can, combining all the worst bits above.
The Code is compiled to intermiary bytecode using a compiler you have never seen, run on a custom VM, split across unsyncronised virtual threads, saved and reloaded with different time clocks on different hardware, then recompiled using a JIT to machine code, is reordered to optimise it to run on a different hardware architecture, then the threads are stopped and started a couple of times just for fun.... then its all brought back together, the results are rounded, types are dynamically converted and the results passed through a couple of API's using subtly different type sizes (say, Lua binding then through a C# wrapper and back to some native C++ and out to a Python script) before being thrown against the wall, wrapped into JSON and passed to a grafted-on GUI running a mixture of Javascript, ASP and Actionscript....on an old handheld game console that has been jail-broken and has an emulator running a stripped down version of Windows 95 a 1/10 expected clock speed and a hand patched copy of IE6 ... and enough Malware to make your eyes bleed.
Can you verify that the code does not do anything that it should not? Can you find "Bugs" using a Unit Test in this scenario? Can you even guess what a "bug" might be in this scenario? The only thing you can do is test for expected functionality and verify if it exists or not.
Welcome to Unit Testing.
I just read the above article and a couple of the comments. The author seems to think that Unit Tests have something to do with finding bugs.
What bugs? Unit testing cannot "find" bugs. A developer can use Unit tests to detect violations of expected behaviour (assuming those unit tests exist). Bugs are conceptual issues that may exist in the developesr expected functionality, the users expected functionality, unexpected functionality, future functionality... etc.
1) Unit Tests can be used to verify that a piece of code "does what it is designed to do". I.e, that it has the expected behaviour or functionality as the designer understands it.
2) Unit Tests can't verify that code "does other things that it was not designed to do" as this is an open ended list. Simple design, encapsulation and composition are better tools to manage this kind of complexity.
3) Unit Tests can be used to verify that code "does not do a specific thing that it was designed not to do" but only once the designer/developer knows enough about the undesirable behaviour to write a specific test for it. This then becomes an instance of the first clause above. However, it does not guarantee that this behaviour cannot occur in an unexpected way. It can only verify that the behaviour does not occur in the way expected by the test.
A developer can use a Unit Test to assert something explicitly about the behaviour of a unit of code and then Verify that Assertion now and in the future.
A developer cannot use Unit Tests to infer something about the behaviour of the code. (Well they could, but it will bite them sooner or later)
A Unit Test is an attempt to treat a piece of code as a deterministic machine.
Sample Data In - > Code Under Test -> Expected Behaviour Out.
This system involves no variables. It's a simple mapping from the input to the output. It has no state except what you inflict on it. This is all a Unit Test can be. Even if you get clever and provide an exhaustive list of sample data and run it all through the code, its still the same case. You cannot assert anything about the behaviour of the code except under the conditions you have tested. You can infer about the behaviour of the code under conditions you have not tested... but its guessing. Not even educated guessing. Certainly not SWAG. It's just WAG.
You CANNOT predict all the conditions that the code could, should, might, maybe run under, now or in the future. You can't come close to guessing what tiny modifications might be done to the code... you can't know if that code will be transcoded to another system, language or hardware platform.... it may be compiled, cross-compiled, JIT compiled, interpretted, it might be "optimised" by hand or tool... you code can be so thoughly changed that you can not reason about it. The language standard could evolve, your code could be compiled by better or worse tools, linted, scrubbed, re-ordered, have other code injected, be mutated at runtime, suffer a stack fault, have its memory corrupted.... malware may interfere, API's change, security software not even invented yet may completely stuff it up. Its even possible that your code could run in a Virtual Machine or some other system that allows pause and restart. You code could have its state saved and reloaded or modified and reloaded... or reloaded on a completely different machine in a cluster... or a different data center on a different continent.. there is just nothing that cannot be munged up given the wrong scenario.
But in every case above, you can still assert intended behaviour and verify if the code satisifes that assertion or not.
Just for fun, imagine the worse possible scenario for the piece of code that you can, combining all the worst bits above.
The Code is compiled to intermiary bytecode using a compiler you have never seen, run on a custom VM, split across unsyncronised virtual threads, saved and reloaded with different time clocks on different hardware, then recompiled using a JIT to machine code, is reordered to optimise it to run on a different hardware architecture, then the threads are stopped and started a couple of times just for fun.... then its all brought back together, the results are rounded, types are dynamically converted and the results passed through a couple of API's using subtly different type sizes (say, Lua binding then through a C# wrapper and back to some native C++ and out to a Python script) before being thrown against the wall, wrapped into JSON and passed to a grafted-on GUI running a mixture of Javascript, ASP and Actionscript....on an old handheld game console that has been jail-broken and has an emulator running a stripped down version of Windows 95 a 1/10 expected clock speed and a hand patched copy of IE6 ... and enough Malware to make your eyes bleed.
Can you verify that the code does not do anything that it should not? Can you find "Bugs" using a Unit Test in this scenario? Can you even guess what a "bug" might be in this scenario? The only thing you can do is test for expected functionality and verify if it exists or not.
Welcome to Unit Testing.
My Wish list for Agent based simulation engine
After looking at a bunch of sim engines and finding a real mix of features, the stuff I am looking for is:
I would prefer a clean codebase that can be compiled using industry standard tools (C++, C# VB, Java, Python) rather than one of the less popular languages or niche languages. The absence of years of cruft would be really appreciated.
For a scripting language, it would be preferable to have something popular and accessible rather than yet another domain specific langauge just because someone wanted to write their own procedural language. I understand creating a language for something like evolutionary computing or something like GA's but not for straight OO procedural scripting. Use python, Lua or one of the dynamic Java dialects. Something with a very well developed set of language tools. A .NET
In World Features
- Define the world and its properties (As an agent or as a special "super agent"... I don't care)
- Define the agent(s) and their properties (Deterministic, GA, Evolvable code, Neural Nets whatever)
- Define framework/helper agents
- Broadcast and narrowcast communication to groups, channels, layers etc
- Transport systems and constraints (Simulate natural or man-made systems to externally affect agents movment)
- Grouping Agents for efficient manipulation of agents (group, list, collection, ripple group, proximity group, ray strip, chain, sequence etc)
- Network structures with relationship sub-elements
- Listener, observer, subscribe kind of models for composition of arbitrary relationships between agents
Out of World Features
- Graphical Interface (Realtime or not... but must have) display, record video, snapshots, timelapse camera. World camers, tracking camera for agents. Layers that can be turned on and off. Stats windows for watching variables.
- Run Control (Play, Pause, Various speed steps, Stop/End/Terminate)
- Multi-Dish - I want to be able to run multiple sims with a synchronised time clock side by side with a master run controls to run,pause,stop them all.
- Rewind (would be nice but I understand why it would be difficult/impossible in many cases for efficiency) This would be nice even if it was just the ability to take a state snapshot every X time-steps and the roll back to an arbitrary time step.
- Explainer, debugger system for analysis of a running sim down to the finest grain agent level.
- Data output pipeline to one or more files and to the network in some fashion
- Networkability (nice to have for bigger sims but not needed for small stuff) some listener interface and talker interface with some simple distributed topology and a master agregator unit.
- Trace and Probe model for analysis of any and all agents in the system. This should allow arbitrary attach and detach during a running simulation. This should also allow setting of agent variables and snapshoting agents state. It would be good to be able to snapshot an agent and "inject" that snapshot back into the agent or another agent.
Platform Features
I don't really care... but it has to be able to be scripted and extended. It would be nice if it runs on windows but I can adapt to anything except OSX. Simply because the Uni is anti-mac this year.I would prefer a clean codebase that can be compiled using industry standard tools (C++, C# VB, Java, Python) rather than one of the less popular languages or niche languages. The absence of years of cruft would be really appreciated.
For a scripting language, it would be preferable to have something popular and accessible rather than yet another domain specific langauge just because someone wanted to write their own procedural language. I understand creating a language for something like evolutionary computing or something like GA's but not for straight OO procedural scripting. Use python, Lua or one of the dynamic Java dialects. Something with a very well developed set of language tools. A .NET
Sunday, November 18, 2012
Is the SIR model applicable for Zombie outbreaks?
I have been playing with SimZombie and thinking about the paper "When Zombies attack! Mathmatical modelling of an outbreak of Zombie Infection" (Availible here). Both are based on the SIR model using a synchronous latice from epidemiology and I think the model is way too simple to be useful.
My problem is that humans in a population do not act like cells or cattle. There are plenty of similarities but its the differences that break the model fundamentally. However, like all thought experiments on imaginary ailments... this is simply a case of my imagination against someone elses...
The problem is that the variables in the SIR model is very simplistic.
Transition from the S to the I state is inevitable goverened only by some probability at each possible infection event. Similarly transition from the I to the R state is also inevitable, again regulated by some probability.
The argument being that the complexity of the system is stripped down and the value of the model is in the understanding of the outcomes given different starting conditions of the variables.
However, I would contend that stripping the population down to such an abstraction, produces a model that is pointlessly simple and, to be honest, boring. I mean, if you are going to spend the time to model an imaginary disease, you may as well enjoy it.
So where to begin? Well let's start by extenting the SIR model a little.
Lets start by looking at a more interesting number of compartments in the model.
S - Succeptable ( This is the "living" population in most scenarios)
B - Bitten (Early stage Infection, but not mentally compromised ...yet)
Z - Zombie (Fully infected classical Zombie. )
D - Dead (This is permaently dead... not undead-dead. This is game-over)
Finally, the most important divergence from the SIR model is the concept that the population is passive. I propose that we add another compartment.
H - Zombie Hunter
I propose that we accept that a certain proportion of the population are not going to be particularly "passive" and will take some steps to at least defend themselves, while others will go to the extreem of purposefully hunting down Zombies.
One of the interesting things is this proposed model is how these hunters will behave over time. If we consider that someone learning to hunt, should improve with experience (learn) then they should become more effective given time. While the other side of this coin may be a resource problem. If they run out of energy or ammo... then they may become less effective over time.
We can still map out the state transition diagram. I think its pretty obvious.
S->B (Got bitten)
S->D (Got dead)
S->H (Got angry)
B->Z (Full blown infection)
B->D (Got dead. Self inflicted, friends, treage )
H->S (Calmed down or out of ammo)
H->B (Got bitten)
H->D (Got dead)
Z->D (Got dead)
The question is always... "is there a cure"? If there is a state transition from Z to S then does it grant immunity or is the individual again succeptable, if not, there would be a true "R" state with immunity.
Anyway, lets have a look at some of the potential variables for the different compartments.
S Compartment
* Movement rate
* Intelligence
* Clustering and Cooperation
* Communication
B Compartment
* Time to full blown infection
* Knowledge of process
* Willingness to self-terminate
* Willingness to hunt full blown Zombies
Z Compartment
* Movment rate of a Zombie
* Intelligence of the Zombie
* "Hunger" rate of the Zombie
* Infection from contact/bite
* Shelf-life. (How long can a Zombie last without food? Is a Zombie Omnivourous? Does a Zombie die of old age? Can a Zombie die from other things? Does a Zombie "fall apart" from wear and tear?)
D Compartment
Apart from being really really dead, are these agents:
* Still infectious?
* A short or long term food source for the Zombies
* Going to drive the behaviour of either the S, B, Z or H compartments
H Compartment
* Experience
* Resources
* Movment
* Intelligence
* Cooperation
*Communication
* Reproduction ( can a H turn an S into a H?)
Now this should make for an interesting model.
I think the general reason that Zombies are so fearsome in all the scenarios is that they are implicitly or explicity given immortality and a reasonable amount of intelligence but not enough to be able to survive. It would be pointless to debate these issues in the context of arguing about an infection model because the assumption is that Zombies have some sort of human seeking drive that makes living people their only food source. In the event that this was true, the logical extensions of become fairly idiotic. Are Zombies cold blooded? If not, how do they maintain their energy needs? Anyway... at some point they will run out of energy and then what? If they can eat something else... then why bother with humans who can be a bit hard to catch? As I said, unless you accept some of these assumptions, the whole game falls apart.
Assumptions:
* Zombie are essentially "Immortal" and do not "die" from anything like disease, decomposition or wear-and-tear.
* Zombies are fixated on fresh humans ( cause the script writer told them too...)
* Zombies are fairly dumb, cannot communicate directly and engage in only basic food aquisition and movment. Essentially they act "alone".
* There is no cure... or the infection process is so destructive there is "nothing left tosave"... so for practical purposes its a one way trip.
The assumption that Zombies are Immortal is problematic because it creates a cascade effect of an increasingly large population of Zombies. In the event that this is "valid" within the scenario, then it does present a challenge for the uninfected. In the event that there is some "decay" model for the Zombies then there would need to be some effect of time on the population of the Zombies. In this case the obvious strategy for the uninfected is to quarantine themselves or the infected and wait it out. The fact that most of the popular fiction around Zombies tends to work in a timeframe where any decay model is not a significant factor means that this is not well explored. (28 weeks Later looked at this "wait it out" model and explored the concept of latent infection "flaring up" again.)
The assumption that Zombies are fixated on fresh meat presents a few problems. While it would probably be fairly easy to access in the early days of an "outbreak" due to the suprise factor. I think that as soon as the knowledge about the outbreak was "released" the availible population of food would disperse and be more cautious. This would reduce the growth rate of the Zombie population simply because the availible population of uninfected were aware and attempting to avoid the Zombies. The other problem is that if a mob of Zombies catch up with a food source, they will probably consume it rather than simply infecting it. So the rate at which contact with Zombies leads to infection rather than death would probably be related to the densitie of Zombies in the immediate area. The other question is how long does it take for a corpse to become unattactive to Zombies as a food source? Would there be a period where a freshly infected Zombie was still "tasty" enough that other Zombies would try to "snack" on each other? In this case, would they try to defend themselves? I which case can you get Zombies to fight each other? Will they fight to the death? Are Zombies smart enough to distinguish between a Zombie that is covered in fresh blood from feeding vs one that is still fresh enough to snack on? This does suggest some fairly advanced reasoning and sensing ability.
The assumption that Zombies act alone is interesting. In most popular culture Zombie outbreaks Zombie populations display emergent flocking behaviour which makes the danger from a single Zombie much more dangerous. For this behaviour to function, Zombies must be able to perceive each other and attribute meaning to others behaviour. This could function simply by Zombies "walking" purposfully when they are on the trail of food, and walking differently when they are "wandering". So any Zombie in "wander" mode who sees another Zombie walking in "pursuit" mode will perceive that they are heading toward food and join in. The key being that the zombie joining the "pursuit" must then change their behaviour to "pursuit" mode as well.
This "model" creates an indirect system of emergent communication within the population of Zombies. The result is that Zombies follow other Zombies and engage in "mobbing" behaviour of "food sources". The question is why a Zombie, who can figure out the difference between another Zombie randomly walking and the same Zombie walking toward food does not use their perceptions for other cognitive functions... just imagine Zombies with Neural Plasticity....
Anyway, the obvious problem with a flocking algorithm that is based on its members following each other is that potentially it can create a "whirlpool" of Zombies following Zombies following the first Zombies. This whirlpool could potentially grow to suck in all the Zombies in the world. Assuming that none of the un-infected are stupid enough to disturb the whirlpool, this would keep all the Zombies occupied until they "timed out".
As I mentioned above, if you follow some of these assumptions they become silly.
My problem is that humans in a population do not act like cells or cattle. There are plenty of similarities but its the differences that break the model fundamentally. However, like all thought experiments on imaginary ailments... this is simply a case of my imagination against someone elses...
The problem is that the variables in the SIR model is very simplistic.
Transition from the S to the I state is inevitable goverened only by some probability at each possible infection event. Similarly transition from the I to the R state is also inevitable, again regulated by some probability.
The argument being that the complexity of the system is stripped down and the value of the model is in the understanding of the outcomes given different starting conditions of the variables.
However, I would contend that stripping the population down to such an abstraction, produces a model that is pointlessly simple and, to be honest, boring. I mean, if you are going to spend the time to model an imaginary disease, you may as well enjoy it.
So where to begin? Well let's start by extenting the SIR model a little.
Lets start by looking at a more interesting number of compartments in the model.
S - Succeptable ( This is the "living" population in most scenarios)
B - Bitten (Early stage Infection, but not mentally compromised ...yet)
Z - Zombie (Fully infected classical Zombie. )
D - Dead (This is permaently dead... not undead-dead. This is game-over)
Finally, the most important divergence from the SIR model is the concept that the population is passive. I propose that we add another compartment.
H - Zombie Hunter
I propose that we accept that a certain proportion of the population are not going to be particularly "passive" and will take some steps to at least defend themselves, while others will go to the extreem of purposefully hunting down Zombies.
One of the interesting things is this proposed model is how these hunters will behave over time. If we consider that someone learning to hunt, should improve with experience (learn) then they should become more effective given time. While the other side of this coin may be a resource problem. If they run out of energy or ammo... then they may become less effective over time.
We can still map out the state transition diagram. I think its pretty obvious.
S->B (Got bitten)
S->D (Got dead)
S->H (Got angry)
B->Z (Full blown infection)
B->D (Got dead. Self inflicted, friends, treage )
H->S (Calmed down or out of ammo)
H->B (Got bitten)
H->D (Got dead)
Z->D (Got dead)
The question is always... "is there a cure"? If there is a state transition from Z to S then does it grant immunity or is the individual again succeptable, if not, there would be a true "R" state with immunity.
Anyway, lets have a look at some of the potential variables for the different compartments.
S Compartment
* Movement rate
* Intelligence
* Clustering and Cooperation
* Communication
B Compartment
* Time to full blown infection
* Knowledge of process
* Willingness to self-terminate
* Willingness to hunt full blown Zombies
Z Compartment
* Movment rate of a Zombie
* Intelligence of the Zombie
* "Hunger" rate of the Zombie
* Infection from contact/bite
* Shelf-life. (How long can a Zombie last without food? Is a Zombie Omnivourous? Does a Zombie die of old age? Can a Zombie die from other things? Does a Zombie "fall apart" from wear and tear?)
D Compartment
Apart from being really really dead, are these agents:
* Still infectious?
* A short or long term food source for the Zombies
* Going to drive the behaviour of either the S, B, Z or H compartments
H Compartment
* Experience
* Resources
* Movment
* Intelligence
* Cooperation
*Communication
* Reproduction ( can a H turn an S into a H?)
Now this should make for an interesting model.
I think the general reason that Zombies are so fearsome in all the scenarios is that they are implicitly or explicity given immortality and a reasonable amount of intelligence but not enough to be able to survive. It would be pointless to debate these issues in the context of arguing about an infection model because the assumption is that Zombies have some sort of human seeking drive that makes living people their only food source. In the event that this was true, the logical extensions of become fairly idiotic. Are Zombies cold blooded? If not, how do they maintain their energy needs? Anyway... at some point they will run out of energy and then what? If they can eat something else... then why bother with humans who can be a bit hard to catch? As I said, unless you accept some of these assumptions, the whole game falls apart.
Assumptions:
* Zombie are essentially "Immortal" and do not "die" from anything like disease, decomposition or wear-and-tear.
* Zombies are fixated on fresh humans ( cause the script writer told them too...)
* Zombies are fairly dumb, cannot communicate directly and engage in only basic food aquisition and movment. Essentially they act "alone".
* There is no cure... or the infection process is so destructive there is "nothing left tosave"... so for practical purposes its a one way trip.
The assumption that Zombies are Immortal is problematic because it creates a cascade effect of an increasingly large population of Zombies. In the event that this is "valid" within the scenario, then it does present a challenge for the uninfected. In the event that there is some "decay" model for the Zombies then there would need to be some effect of time on the population of the Zombies. In this case the obvious strategy for the uninfected is to quarantine themselves or the infected and wait it out. The fact that most of the popular fiction around Zombies tends to work in a timeframe where any decay model is not a significant factor means that this is not well explored. (28 weeks Later looked at this "wait it out" model and explored the concept of latent infection "flaring up" again.)
The assumption that Zombies are fixated on fresh meat presents a few problems. While it would probably be fairly easy to access in the early days of an "outbreak" due to the suprise factor. I think that as soon as the knowledge about the outbreak was "released" the availible population of food would disperse and be more cautious. This would reduce the growth rate of the Zombie population simply because the availible population of uninfected were aware and attempting to avoid the Zombies. The other problem is that if a mob of Zombies catch up with a food source, they will probably consume it rather than simply infecting it. So the rate at which contact with Zombies leads to infection rather than death would probably be related to the densitie of Zombies in the immediate area. The other question is how long does it take for a corpse to become unattactive to Zombies as a food source? Would there be a period where a freshly infected Zombie was still "tasty" enough that other Zombies would try to "snack" on each other? In this case, would they try to defend themselves? I which case can you get Zombies to fight each other? Will they fight to the death? Are Zombies smart enough to distinguish between a Zombie that is covered in fresh blood from feeding vs one that is still fresh enough to snack on? This does suggest some fairly advanced reasoning and sensing ability.
The assumption that Zombies act alone is interesting. In most popular culture Zombie outbreaks Zombie populations display emergent flocking behaviour which makes the danger from a single Zombie much more dangerous. For this behaviour to function, Zombies must be able to perceive each other and attribute meaning to others behaviour. This could function simply by Zombies "walking" purposfully when they are on the trail of food, and walking differently when they are "wandering". So any Zombie in "wander" mode who sees another Zombie walking in "pursuit" mode will perceive that they are heading toward food and join in. The key being that the zombie joining the "pursuit" must then change their behaviour to "pursuit" mode as well.
This "model" creates an indirect system of emergent communication within the population of Zombies. The result is that Zombies follow other Zombies and engage in "mobbing" behaviour of "food sources". The question is why a Zombie, who can figure out the difference between another Zombie randomly walking and the same Zombie walking toward food does not use their perceptions for other cognitive functions... just imagine Zombies with Neural Plasticity....
Anyway, the obvious problem with a flocking algorithm that is based on its members following each other is that potentially it can create a "whirlpool" of Zombies following Zombies following the first Zombies. This whirlpool could potentially grow to suck in all the Zombies in the world. Assuming that none of the un-infected are stupid enough to disturb the whirlpool, this would keep all the Zombies occupied until they "timed out".
As I mentioned above, if you follow some of these assumptions they become silly.
Thursday, November 15, 2012
Agent Based Simulation Engines
COS Sim - Traffic flow simulation
http://code.google.com/p/cos-sim/
SimZombie - This looks like fun
http://code.google.com/p/simzombie/
XMLisp - Seems like a simulation toolkit or a simple game engine.
http://code.google.com/p/xmlisp/
MASON - This one looks quite well developed.
http://cs.gmu.edu/~eclab/projects/mason/
RePast - Looks well developed and flexible.
http://repast.sourceforge.net/
AScape
http://ascape.sourceforge.net/
This is yet another Java based engine for doing 2d simple agents in a simple world. This is even more rigid as it uses a latice world.
Swarm
http://www.swarm.org/index.php/Main_Page
http://www.swarm.org/index.php/Swarm_main_page
http://www.swarm.org/images/b/bb/MinarEtAl96.pdf
Objective-C.... mmmk. Reading the ideas page gives you a bit of an idea of the amount of baggage that this system is dragging around with it. It looks like a very nice package but its got bloat and is trying to be all sorts of things to too many people. I think once you spilt your efforts across one or more languages... its all over... the efforts of the community get sucked up by having to duplicate everything and trying to support new work with a foot on both sides of the langauge barrier. It just buries the pace of evolution. I think rob the system for all the good ideas and start again clean. .NET across Mono is probably the easy solution with some front end work done in HTML5 for simple cross platform support.
Breve
http://www.spiderland.org/
This looks like a nice little package. Fast and easy to set up with a good graphics engine already in place. Has a good set of docs and examples. Spot the teaching tool. I could do some things with this. There is some framework already in place but some you would need to implement. Have not looked at the source yet.
The Mega List of Agent Modelling Software
http://en.wikipedia.org/wiki/Comparison_of_agent-based_modeling_software
Subscribe to:
Posts (Atom)