Added Gini solver

[bvssvni]

• Added random_transactions_solver example
• Modified random_transactions to find next batch of data for
  stochastic convergence
• Added Dyon data “data/smooth.dyon” for stochastic convergence
• Added “data/first-solver.ods”

What is mix-economy?

Mix-economy is a simple algorithm that I am researching with the hope to use it for automatic balancing of virtual economies in MMOs. It turns out that like in the real world, when economic inequality gets too large, measured by the Gini coefficient, it can slow down the economy.

I want to experiment with gameplay that allows players to script computers inside the game. This leads to an interesting theoretical problem when you try to make the game fun for both casual and experienced players. For high levels of automation, new players can be discouraged from joining because it is very hard for them to earn money. Using automatic balancing, but in a way that incentivize players to participate and invite new ones, might solve distribution of wealth when the economy is heavily pressured by automation. (I want ever-more sophisticated AIs as part of the game!)

What is the big deal with a Gini solver?

The mix-algorithm uses negative fortune (or income) tax below a soft limit together with a universal basic income, and "burns money in the pocket" of players above the soft limit to control inflation. The entire algorithm is controlled by a single parameter: The tax rate.

The Gini solver figures out how to set the tax rate automatically to meet a target for inequality. This means players can agree on a Gini coefficient and then compete for rewards within the constraints of the mix-algorithm.

Here are the results of the first run using the solver, under random transactions:

As seen in the graph above, it keeps the Gini close to the target for the most common range. If this is true for most settings and patterns of economic activities, then we might have reached the goal of this research project!

Further testing and improvements

The solver has not been tested thoroughly, but I am merging this so other people can test it too. We need to find out where the solver is weak, and whether other parameters should be improved.

Also, there is probably room for performance improvements, although the solver does not need to run often.