Monthly Archives: January 2016

Simulating Greed Results – Part 1

So the first round of simulations have been finished and the results have been very interesting. On the one hand, the results are pretty much what you’d expect; greed by one entity affects the entities closest to the greedy one. On the other hand, because this simulation makes it possible to monitor total throughput, it allows us to quantify and measure the impact of greed on the complete system. In other words, this simulation can be thought of as a way to study the impact of greed on the GDP of the system.

In the first round of testing, every farmer tries to turn on the water no more than 3 times a second. The nap() method in BasicBirds get a random value between 10ms and the nap length value for each bird after each time the bird has eaten. This means that “lucky” birds will attempt to turn on the water more frequently because the Java random number generator produced lower nap numbers. Unlucky birds will attempt to turn on the water less frequently, again because the Java random function generated higher nap numbers.

Luckiness also manifests itself in another way. Because each farmer (bird) must successfully get two shared resources, a farmer must be lucky enough to try to turn on the water when neighboring farmers aren’t already using the water. Sometimes trying more frequently just means failing more frequently. In general, however, trying more frequently results in water being turned on more frequently.

So in the first round of testing with all the farmers set up the same way, all of the farmers had pretty similar results. Some failed more than others, some succeeded more than others, but it was always different farmers in each run who succeeded or who failed. The consistent variability of the results provides assurance that ConcX isn’t favoring one farmer over another and biasing the outcomes. Click on the charts below to see the full charts.

TotalFails300all

Total Failed Attempts and Successful Attempts

TotalDeliv300all

Total Amount of Water Delivered by Run

TotalDiff300all

Difference Between Farmers Receiving Most and Receiving Least

 

 

 

 

 

 

AmtDeliv300AllRun1

Run 1 – Ajia1 Received Most Water

AmtDeliv300AllRun2

Run 2 – Dave1 Received Most Water

AmtDeliv300AllRun3

Run 3 – Irma1 Received Most Water

 

 

 

 

 

 

The actual numbers reported in these runs are unimportant. With this first round (3 runs) what’s important is that most of the farmers are receiving similar amounts of water and the differences attributable to luck or chance. This round establishes the baseline that will be used for comparison to later rounds of testing.

In the next round of testing, one of the farmers is changed to try to turn on 3 times more frequently than the other farmers. Which farmer is selected is completely arbitrary; any of the 10 farmers could have been selected and similar results would have been achieved. In these results, Bill1 was selected to be greedy and try more frequently to get water.

The following results show that the number of failed attempts has gone up slightly even though the total number of successful attempts is almost unchanged. The total water delivered is also almost unchanged; it goes up slightly. The biggest change is seen in the Difference chart (Farmers: Max Deliv vs Min Deliv). The Max amount that any one farmer received (Bill1) has gone up while the least amount that any one farmer received (Ajia1 or Cate1) has gone done. Again, be sure to click on the thumbnails below to see the details.

TotalFails100For1

Successes & Failures – 1 Slightly Greedy Farmer

TotalDeliv100For1

Total Water Delivered – 1 Slightly Greedy Farmer

TotalDiff100For1

Differences – 1 Slightly Greedy Farmer

 

 

 

 

 

AmtDeliv100Run1

Bill1 is Greedy Farmer – Ajia1 and Cate1 Suffer – Run 1

AmtDeliv100Run2

Bill1 is Greedy Farmer – Ajia1 and Cate1 Suffer – Run 2

AmtDeliv100Run3

Bill1 is Greedy Farmer – Ajia1 and Cate1 Suffer – Run 3

 

 

 

 

 

 

In the next round of testing (3 runs), the greedy farmer becomes even greedier and tries to turn on the water 10 times more frequently than the neighboring farmers. Again, the farmer that was selected was completely arbitrary.

TotalFails30For1

Total Failures & Successes – 1 Greedy Farmer

TotalDeliv30For1

Total Amount Delivered – 1 Greedy Farmer

TotalDiff30For1

Differences Max & Min – 1 Greedy Farmer

 

 

 

AmtDeliv30Run1

Run 1 – Edna1 is Greedy Farmer – Dave1 and Fred1 Suffer

AmtDeliv30Run2

Run 2 – Edna1 is Greedy Farmer – Dave1 and Fred1 Suffer

AmtDeliv30Run3

Run 3 – Edna1 is the Greedy Farmer – Dave1 and Fred1 Suffer

 

 

 

 

 

 

 

 

The results of this round of testing are similar to the previous run; the total number of failed attempts have gone up while the total number of successful attempts is about the same. The total amount of water delivered is moving slightly higher. However, the difference between the maximum amount delivered to a farmer (Edna1) has gone significantly from before while the amount of water delivered to the least fortunate farmers (her neighbors Dave1 and Fred1) has dropped significantly.

One lesson that could be taken from these three rounds of testing is that the total amount of water delivered to the whole system doesn’t go up significantly by allowing one farmer to be more greedy. In this example, the gains of one greedy farmer is greater than the losses of the neighboring farmers. The biggest difference from one test to another has been in the “inequality” in the distribution of water; the additional water that the greedy farmer gained has come at the expense of the neighbors.

It is tempting to draw conclusions from these results, that in societies where there are limitations to resources (every society on earth) that the greediness of an individual is frowned upon because it doesn’t significantly increase the overall amount of product while increasing the hardship of others.

But is this always the case? What happens if death is introduced into the system? Followers of Avian Computing know that birds dying from lack of food has been part of the system design from the beginning. In the next rounds of testing, farmers who receive insufficient water are allowed to give up and move away because their crops died because of lack of water. While this seems cruel, it is in keeping with standard economic theory, where producers with a “competitive advantage” succeed while less efficient producers are allowed (or encouraged) to give up making their current product and begin making a new product.

Stay tuned for the next results.

Simulating Greed

One of the unexpected benefits of Avian Computing and ConcX is the relative ease that simulations can be developed. ConcX is based on an asynchronous model with loosely-coupled threads, allowing the threads to dynamically adjust to their environment, the way that individual birds in a flock would dynamically adjust to their real-world situations.

I was remarking to a friend that the Dining Philosophers problem was interesting because it was a dynamic representation resource allocation much discussed and dissected by standard economics. Further, when using ConcX to solve the Dining Philosophers problem, I had noticed that it was possible to give one philosopher “competitive advantages” over the other philosophers. And that was when the Simulating Greed project was born.

Diagram 1. Basic 10 Farmer Setup.

The Simulating Greed project begins by increasing the number of participants and resources. And to make it a little more realistic, the philosophers were changed to Farmers and the resources changed from forks to Faucets. Every Farmer wants to water his crops. To do that, a Farmer must turn on two Faucets, one on each side of their property. See Diagram 1. Each Faucet is shared with the Farmer’s neighbors and can be set to provide water to one Farmer or the other but not both. Each Farmer, when they have control of both Faucets, can also set how long they will receive water.

Varying levels of greed can then simulated by the Farmers by how frequently they try to water their crops and how long they set the water to run. A greedy Farmer will try to water their crops very frequently and will also set the water to run a long time. A less greedy Farmer will try to water less often and for shorter durations.

In this simulation, the assumption is that greedy Farmers always want as much water as they can possibly get. More water is always assumed to be better and there is no limit to the supply of water. In real life, there is an effective limit to how much water a single farmer can use and to the amount of water available.

Another factor in the simulation is whether or not Farmer death is allowed. A Farmer can be configured to never die, regardless of the amount of water they have received, or they can be set to die if they haven’t received water within some configurable time period. This factor can have a significant impact on the results because dead Farmers no longer compete for water. If a Farmer dies early, the neighbors of that Farmer find it easier to get water.

Basic Setup

The Farmers have properties all in a row, with Faucets between each pair of properties. The basic setup has 10 Farmers with 10 Faucets. Each neighboring pair of Farmers have to share the Faucet between them. And to make demand even, the two end neighbors have to share with each other, even though they are furthest apart. See Diagram 1. This setup makes each Faucet a shared resource for 2 Farmers.

Note that Faucet 10 is shared between Ajia1 and Jack 1. There should be a dotted line that runs between these farmers, but there wasn’t any clean way to draw this relationship without cluttering up the image. Instead of the dotted line, Faucet 10 is shown at both the top and bottom of Diagram 1with half of the valve grayed out; you’ll have to use your imagination to draw in the water line between them. Ajia 1 and Jack 1 must share a Faucet to make it a closed and equal system where they both must compete with two other Farmer, just like all the rest.

Advanced Setup

farmer20a

Diagram 2. Setup for 20 Farmers.

The number of Farmers is increased to 20 but the number of Faucets remains unchanged. See diagram 2. This setup makes each Faucet a shared resource for 4 Farmers.

Even More Setups

The number of Farmers is increased to 40 and 80 but the number of Faucets remains unchanged. There is no diagram for these setups because I can’t visualize a configuration of Farmers that would allow the to share the Faucets without moving their farms into satellites in outer space. With 40 Farmers, each Faucet is a shared resource for 8 Farmers. With 80 Farmers, each Faucet is a shared resource for 16 farmers.

Settings

Nap times are initially set to 300ms for each Farmer. The length of time they keep the Faucet on is initially 300ms. The amount of water delivered to a Farmer is calculated based on the number of milliseconds the Farmer keeps the water flowing and the number of times the Farmer successfully turns on the water. For example, a Farmer who successfully turns on the water 7 times for 300ms receives 2100 units of water. If the Farmer’s neighbor successfully turns on the water 7 times for 500ms receives 3500 units of water.

Summarizing Results

Each Farmer keeps track of his own results during each simulation run. When the Farmer terminates (either by early death or end of natural life), they write their individual Results to the TupleTree. A Summarizer bird is running during the run and any time a Farmer dies for any reason, the Summarizer eats their Results and adds their stats to the stats for the other users. For example, Ajia1 had 100 units of water delivered and Cate1 had 200 units of water delivered, so the Summarizer records that 300 units of water had been delivered.

When the Summarizer terminates, it writes its Summary info to the TupleTree. When the user selects the TupleTree tab and clicks the Show Tree button, all of the Food items in the tree are listed. The ResultsProcessed Food items contain summaries of the results for individual Farmers. The Summary Food item contains the totals for all Farmers as well as detailed summaries of each bird in it’s Content object. To see the SummaryDetails object contained in the Summary.Contents object, enter a filename in the field at the bottom of the TupleTree tab and the press the Save button. Any object contained in a Contents object will print the values that they hold IF that object implements the toDetailString() method. Otherwise it will print the info generated by that object’s toString() method.

In Conclusion

All together, the new features available in the TupleTree combined with saving the results of the runs provides the ability to analyze how individual Farmers are affected by the greed of their neighboring Farmers. More about those results in the next blog.