Some time back (more than 4 years ago) I experimented with Craig Reynold’s boids concept. I suppose everyone does boids some time or another. I called mine Utopia and wrote a simple simulation game around it, where two groups of opposing boids clashed with each other, try to eat each other up. Macabre, I know but it was pretty cool.
I was reading The Origin of Wealth by Eric Beinhocker recently. One of the chapters described Epstein and Axtell’s research in Sugarscape and it reminded me of Utopia. I thought why not to try reproduce it with some of what I did in Utopia but in Ruby? After some initial hiccups trying to find the best GUI toolkit to create Utopia2, I decided to use JRuby and Swing.
A bit of background on the subject matter. Joshua Epstein and Robert Axtell are researchers in the Brookings Institution, a public policy think-tank in US. The Sugarscape project was basically an attempt to use ideas from complexity theory and artificial life on to the social sciences. The goal is to see if behaviours we see in real societies can be modelled using just simple local rules, very much like the three basic rules used in modelling boids.
Sugarscape simulates the behavior of artificial people (agents) located on a landscape (50 x 50 grid) of a generalized resource (sugar, hence Sugarscape). Agents are born onto the Sugarscape with a vision, a metabolism, a speed, and other genetic attributes. Their movement is governed by a simple local rule: “look around as far as you can; find the spot with the most sugar; go there and eat the sugar.” Every time an agent moves, it burns sugar at an amount equal to its metabolic rate. Agents die if and when they burn up all their sugar.
So, at each turn the agents follow these basic rules:
- Look around itself, within the constraint of its scope of vision (north, south, east and west)
- Determine which direction has the most sugar
- Move to that square and if it has sugar, eat it
- When it eats some units of sugar, it gains that amount while the sugar on the square is decreased by the amount that is eaten
- Every turn the agent will consume a certain amount of sugar according to its metabolism
- If the agent runs out of sugar it will die. The agent also has a preset lifespan which is reduced every turn until it expires
Sugar is distributed unevenly in Sugarscape, some cells have higher concentration of sugar while others have lower and two sugar ‘mountains’ are formed at the top right and bottom left of the simulation. Sugar that is consumed is also grown back at the rate of one per unit of time, so the food never really runs out.
The simulation starts with 250 agents started at random places. The diagram below shows the output of the basic model, from Epstein and Axtell’s research.
Utopia2 follows a very similiar logic as with Sugarscape but instead of agents and sugar, I used the terms alf (Artificial Life Form) and food. There are also a number of differences:
- While Sugarscape is a 50 x 50 grid, with each agent occupying a cell, Utopia2 is a 600 x 600 canvas and each alf occupies a single point
- Instead of looking at the 4 directions only, each alf scans a radius of its vision scope to see if there is any food within its scope. If there is, it will move towards the nearest visible food, otherwise it will randomly wander to a direction. This differs from Sugarscape because the Sugarscape agent always goes to the direction where it is most likely to have food, whereas the Utopian alf has no idea where the most likely food is, beyond its scope of vision
- The alf also has a lifespan which amount is randomly assigned and is reduced every round. But more importantly if it runs out of sugar, it will not die immediately but it will increase its starvation rate. The alf’s starvation rate quickens the reduction of its lifespan and once its lifespan is 0 it will die
- Lastly, while the Sugarscape agent moves one cell per turn, the Utopian alf has different speeds which is also a randomly distributed endowment. This is actually why the alf is more life-like. Of course my alfs also have a cool-looking ‘tail’ :)
Besides this, in Utopia2 while food grows back, it doesn’t do so immediately but grows back at a different rate. The result is as shown in this YouTube clip.
Here are some still shots of the simulation and two charts that trace the the progress of the simulation.
The first chart shows the food level of each alf over the progression of the simulation. In t=0, the alfs’ food levels are evenly distributed, that is, some have more food than the others but overall, the gap is not large. As the simulation progresses, you’ll notice that the chart becomes a sort of power law graph, where there are some alfs with a lot of food, while most will eventually have either very little or none (dead).
The second chart shows the number of alfs compared with the amount of food (in ranges) it has. I took the food levels of all the alfs, and divided the difference between the most food with the least food with a 13 different ranges or food ‘bins’. Then I sorted the alfs accordingly into each bin. In t=0, the distribution, as expected is quite even, and it forms a sort of uneven bell curve. This is expected as the initial food levels of the alfs is a random distribution.
However, as the simulation progresses you’ll notice the chart starts to skew towards the left, with few very ‘rich’ alfs with a lot of food to the right, a long tail of ‘middle class’ alfs and a lot of alfs with little or no food (dead). In fact, in certain simulations, while the alfs start of with a random food level of between 0 – 100, the super-rich alfs can reach levels of more than 7,000!
You’re right if you notice that these two charts basically potray the same thing, and in fact it is the same results that Epstein and Axtell came up with from their Sugarscape model.
So what does Epstein and Axtell’s research show?
In 1895, Italian economist Vilfredo Pareto collected income data from a number of countries and created a distribution chart called the Pareto distribution. Rather than a bell-shaped curve, which it will be if it is a normal distribution, it was one with a few very rich people, a wide range of middle class people and a large number of poor people, what is sometimes also known as power law distribution. In fact you’d probably have heard of this one before – this is the 80-20 rule, where 20% of the people owns 80% of the wealth.
And the Sugarscape (and Utopia2) simulation model shows this.
The question is, why does this happen? Why does the rich get richer and the poor gets poorer? Two obivious answers to this question are:
- Because of their genetic predisposition (nature) i.e. because they were ‘born’ with better endowments – with more scope of vision, with larger appetites, with faster speed etc
- Because of their location (born with a silver spoon) i.e. because they were born at the right place at the right time
However if we dig deeper, both answers are not right, because in each case the distribution is random and therefore bell-curve distribution, if these are the reasons then the final distribution of wealth should also be bell-curve.
The real answer, apparently is described in complexity theory. The skewed Pareto distribution we see is an emergent property of the system, and not because of a single cause. Without going in depth, what it means is that from a simple set of rules rises a new complexity that cannot be easily derived from the existing set of rules.
If we apply it to the real world, the parallels can be that there is no single easy cause of why the rich gets richer and the poor gets poorer, not only because of oppressive explotation by the rich, or globalization, or protectionist policies or the laziness of the people or the color of the skin or whichever the cause of the day is.
If you want to try out Utopia2, I’m making it available here, under Apache 2 license. You’re free to take it up and do whatever pleases you, but I’d appreciate it if you reference me if you do use it. You’ll need JRuby, of course, and JFreeChart.
By the way, this model of the Sugarscape simulation that I have just described is just the basic model. The full work done by Epstein and Axtell is described in their 1996 book Growing Artificial Societies: social science from the bottom up from MIT Press. Utopia2’s implementation to date follows this basic model only, however it is really quite simple to program the other more complex models. Let me know if you use Utopia2 to do this, I’ll be interested in knowing how you do it.
I think something that probably no-one has covered so far in any Seaside blogs is how to send SMTP emails through Seaside or Squeak. If you’re doing a public Seaside application you’ll probably end up having to send emails for various reasons like resetting of passwords or alerts to users etc, so this is something useful to have up your sleeves.
There are a number of ways to send an email in Squeak and Seaside and I know of 3 at the moment.
1. There is a utility class, which contains only class-level messages, called SeasidePlatformSupport, and it has a message called ‘deliverMailFrom: to: text: ‘ that sends a mail directly. However, you’ll need to set the SMTP server first, by using MailSender.
This is a code snippet you can cut and paste directly on to a workspace to evaluate(though obiviously replacing the appropriate email addresses):
MailSender setSmtpServer. SeasidePlatformSupport deliverMailFrom: '<fromEmail>' to: #('<toEmail>') text: 'Subject: Hello from SeasidePlatformSupport! Sending from SeasidePlatformSupport'.
Don’t worry that the setSmtpServer message doesn’t take in any parameters. What happens is that MailSender pops up a dialog box for you to enter the SMTP server. But you’ll need to enter an SMTP server that doesn’t need authentication because there isn’t a way to set the user name or password from this mechanism. Of course you can’t set the mail server from Seaside either (the dialog box is Morphic) but you can run the MailSender once from the Squeak environment and you’ll be good for the rest of the application. Notice the ‘to’ is actually an array of recipients.
2. The second way is to go directly to the MailComposition class that SeasidePlatformSupport is using (through MailSender). This is another piece of code snippet that you can directly evaluate from workspace:
MailSender setSmtpServer. msg := (MailMessage new setField: 'to' to: '<toEmail>'; setField: 'from' to: '<fromEmail>'; setField: 'subject' to: 'Hello from MailMessage!'; body: 'Sending from MailMessage'; yourself). (MailComposition new sendMailMessage: msg) submit.
Again you’ll need to set the MailSender SMTP server first. There isn’t any much difference in doing it this way, as far as I can see, but this is another way you can send emails.
3. Another way is directly go to the underlying guts of the other two mechanisms and use the SMTPClient class itself to send the email. SMTPClient subclasses TelnetProtocolClient and if you dig a bit deeper you’ll realise that it does nothing but to open up a socket session at the appropriate port and send in the SMTP commands as text.
username:= '<aUsername>'. password:='<aPassword>'. client := SMTPClient openOnHostNamed: '<yourSmtpServer>' port: <portNumber>. client user: username; password: password; login; initiateSession. client mailFrom: '<fromEmail>'; recipient: '<toEmail>'; data: 'Subject: Hello from SMTPClient! From: <fromEmail> To: <toEmail> Sending from SMTPClient!'. client quit.
This is actually the underlying code that sends the mail in the first two mechanisms though they are couched by different classes. Of course ultimately you can use TelnetProtocolClient itself to do the work but that’s a bit going down to the basics too much :)
Note that this last method of sending emails you can authenticate the SMTP server and also set the port number.
So the final day has arrived and as in previous years, JavaOne ended on a rather quiet and subdued note. The general session on the last day was by James Gosling (for those uninitiated, the ‘Father of Java’) and his session was called ‘The Toy Show’. It featured a whirlwind of 12 demos aimed to display the wide range and variety of uses in the industry, from meat weighing machines to toy robots to terrain scanning helicopters. It was a pretty interesting session which highlighted the extended reach Java have in all aspects of software development today, though I dare say that this is really nothing compared to the reach C has in the market.
The only interesting technical session (at least in my opinion) that followed was the one on Java ME data binding by Sun Microsystems. I missed the earlier one where a new flashier UI using SVG was discussed but nonetheless, it was quite interesting how much further Java ME is going to go in the coming months and years.
I met up with Watt after that and he brought me across the Golden Gate Bridge to Sausalito for dinner where we had California styled sushi, which for the record tastes nothing like the Japanese food I have so often in Singapore.
I’ll be heading back to sunny Singapore tomorrow with a tired body but fresh new ideas and technologies. It was a good trip all in all.
Today’s sessions were a mixed bunch. I started off with a rather droning session in the morning, coupled with a strong accent from the presenter (I think he’s from Russia or some Eastern European country) and the late night last night made me drowse off half the session on object-oriented databases in Java ME. I feel rather guilty on this because this is a rather useful utility that is open sourced under GPL.
The session that got me awake and interested was the one on JavaFX Script, previously known as F3 (Form Follows Function), the much talked about new technology from Sun. It really isn’t Java the programming language per se, it’s a totally different new programming language, as Chris Oliver, its inventor explained, but one running on the Java platform. Although it’s called a JavaFX Script, it’s not really a scripting language either. Confused? I think most people would be, considering that it just came out a couple of days ago and it’s inventor claims that it’s already a misnomer.
Anyway, the ultimate aim for JavaFX Script was to be compiled into bytecodes and not as it is today interpreted by a JavaFX interpreter. It is also supposed to be ultimately deployed on the browser through the Java Platform (today it’ll be the Java Plugin) althought right now it’ll run only on the desktop or through Java Web Start (there’s a cool calculator at Chris Oliver’s blog that uses this). The concepts are pretty interesting — it’s took the idea of a component based GUI toolkit (like Swing), peppered it heavily with influences from SVG and delivered it as a full programming language that is statically typed to allow a developer to create very compelling UIs.
So what does it have that others don’t already have? Frankly speaking I have no idea. If anything I thought Actionscript already does something like this in Flash and I’d imagine Silverlight would have too though I’m unfamiliar with either. From the session and the Q&A subsequently what I gathered is that there probably isn’t anything else other than making the developer more efficient and effective.
Another interesting session that I attended was on data mining. In fact I just got to know that there was a JSR-73 that was for data mining in Java. I went for it as I was mighty curious on data mining (after the several report related issues in office recently) and I was quite surprised at the complexity and sophistication in this domain. In fact many of the things which I have never thought was related to data mining, was related to data mining. For example one of the things I took for granted was ‘cross selling’, which is to say, if you buy beer, it could be a good idea to try to sell you chips as well (e.g. in put them together in a supermarket) as it has a very high chance of success. There is in fact a data mining method called Market Basket Analysis which provides algorithms to do this. Very cool.
I also attended a session on BD-J, that is, writing Java applications on the Blue-Ray disc. This is mostly revolving around writing the startup menus and other add-ons like games and such for DVD releases, though I can imagine other things can be done on it in the future once it’s properly released. I thought it was pretty cool as well though it’s way out of my domain (mostly it’s for studios and production houses — one of the speakers who was sharing experiences was from Disney).
After soaking up tech stuff for most of the day, I went for the After Dark Bash and it was quite a circus sideshow. The first thing that greeted me when I went in was a mini-concert by a group of ‘vertically-challenged’ entertainers. That is to say, they were a bunch of dwarf singers decked out like KISS (the heavy metal group) belting out heavy metal songs. There were various kinds of food and drinks (two drinks coupons per person) like burger, hotdogs, popcorn, beer, wine, soft drinks and the like and the whole hall was turned into a massive entertainment center with pinball machines, XBoxes, mini-inverse bungees and even a section for people to try out Segways.
But the main attraction was probably the Battlebots arena where there was an exhibition tournment where robots battle it out in very rough conditions trying to smash each other up to scrap metal. Very cool and I suppose very American as well. During an intermission, there was even a totally wierd ‘performance’ by Grindergirl, who came into the ring with a grinder and proceeded to create sparks by running the grinder over her metal-covered body very seductively. There was a collective groan when she moved the grinder over her crotch and created sparks that shot out seemingly from her nether regions.
Have to see to believe.
This will be a short post. I’m tired, it’s almost 3am and I have another full day tomorrow (not to mention the After-Dark Bash, which I look forward to, since I’ve not been to one in the previous years). Today’s session for me have been filled with JavaCard related technical talks and one on software as a service (SaaS) with an experimental Sun project called Project Caroline.
Briefly, I learnt a great deal more on JavaCard 3 today. I attended 3 sessions on JavaCard and 2 of them are about JavaCard 3. It’s true — JavaCard 3 will have a servlet engine based on Servlet 2.4 and will be multi-threaded but it will require 32-bit microprocessors in the chip. Gemalto even has a pretty neat AJAX contact management servlet app running as a demo. This is a first glimpse of the architecture, as presented during a session by Joe Wei from the JavaCard team:
As you can see, it will have both ‘classic’ APDU protocol as well as the new ‘connected’ HTTP/S protocol stack. However there are lots of questions still unanswered.
I took my usual picture with Duke.
But the biggest surprise of the day was that I met Dennis. Yes, of all the people to bump into, it was him. He was here on a business trip and by chance he decided to drop into JavaOne as a pavillion visitor. But here he was. The first time I was in JavaOne was with Dennis 7 years ago and 7 years later here we are again, at the same place. Different, with the intervening years and both of us are much older and maybe wiser (?) and more experienced. We had dinner together at Mel’s Dine-In to reminisce on old times, of the heady days of past and the tumultuous days when the world crashed around us
Life is sometimes a funny thing.