bazaarBot
bazaarBot copied to clipboard
larsiusprime
The Research Paper is Garbage
Thank you for writing this, you've done a good job putting the sourced research paper/technical report into code. Unfortunately the technical report is garbage. I've spent the last few days trying to fix some of the major issues (I can see in the code you tried to address some of the problems as well). The following is a quick summary.
Quick Observations that Something is Wrong When running the program you can observe issues. All prices are more or less random and trend towards pennies. No agents are profitable, they just go bankrupt faster or slower depending on idle time and resource costs. Refiners spend the most and go bankrupt rapidly--I noticed you added a special case in code to get them back based on demand when they all die off. The entire point of the paper is to find prices in a simulated economy, however this function is not accomplished and I claim cannot be accomplished using the methods described in the paper.
Critical Issues in the Technical Paper
-
The first thing I noticed was that the described double auction algorithm in the paper is not a proper double auction. Trades should never execute at prices below the seller bid, nor above the buyer ask, yet the described algorithm does not prevent either case. In particular the seller does not have proper control of the prices they are getting to allow them to be profitable. At first I thought this was why agents weren't profitable, but I quickly found a larger problem...
-
Commodity prices in the sim have some interaction with supply/demand but have no foundation in production costs, so agents cannot be profitable. Nor will discovered prices have much of a relation to the simulated economy. Bids (and asks) are random values in a range that was based on observations of past trades (which were also set randomly). So prices will cluster for a while at randomly found ranges somewhat effected by supply and demand, but none of the prices found will actually be relevant. A particular glaring omission is the agents described in the technical paper do not take into account their costs when setting asks so have no hope of being profitable beyond random chance. Also discovered commodity prices do not reflect the value that actually went into producing those commodities. So prices are nonsensical, agents just go bankrupt, and the result of the simulation is meaningless.
A Few Fixes For the first issue, adding a line to break out of the bid/ask trade processing loop in resolveOffers() when buyer.unit_price < seller.unit_price seems to patch the major problem. Other improvements can be made, but issue 2 is much more critical.
The second issue requires expanding Inventory to track the average price paid per unit for all purchased commodities in addition to commodity count. I changed the Float in Inventory._stuff to be a Point to hold the extra value. I added a BasicAgent.consumeInventory and BasicAgent.produceInventory to be called instead of changeInventory to help identify inventory changes that should track production costs. Money lost due to being idle in Logic.perform also needed to be tracked. Agent logic should change to make all _consume() calls before each _production() call is made so costs are tracked before production.
Once costs are tracked, Agents can then take those costs into account when setting ask levels for their produced commodities to allow for a profit. In fact once you track costs associated with producing a commodity, it immediately becomes apparent that ask price selection as simple as: askPrice = costs * profit_factor. If asks aren't hit, profit_factor can be reduced. Meanwhile the ask selection method in the technical paper is nonsense.
After making the above changes I observe that agents can be profitable, prices stabilize, and they relate to each other reasonably given how some commodities have more value in them based on what goes into producing them. Supply/demand dynamics are simulated as before. Initial conditions for each commodity had to be modified as discovered prices were more than random nonsense and the initial conditions became important.
I would make a pull request except I ported the Haxe project to C# as I'm unfamiliar with Haxe. Also I'm still messing around with things.
Hey! Thanks for this! I had some suspicions that some pieces were missing because I often observed some of the same things but never quite had the time to put my finger on it.
Are your changes available somewhere? Even if they're in a different programming language when I have a free moment I might try backporting them.
The project is only on my computer at the moment, and I'm still adding changes. I could email it to you if you want. I could put it up on GitHub but I only just made this account and don't really know how to do that.
Works for me. Lars dot doucet at gmail dot com.
On Fri, May 25, 2018 at 1:19 PM, Vibr8gKiwi [email protected] wrote:
The project is only on my computer at the moment, and I'm still adding changes. I could email it to you if you want.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-392140612, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-K0P-HiHSDDDmbbIs6irnrw3tgoLks5t2EszgaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
I sent you a copy. I'm still working on it... it's acting better but still some things I think might be off. Eventually I want to add more interesting agents, but I need to make sure I understand what its doing and that its working as it should.
Cool, really appreciate it!
On Fri, May 25, 2018 at 1:51 PM, David [email protected] wrote:
I sent you a copy. I'm still working on it... it's acting better but still some things I think might be off. Eventually I want to add more interesting agents, but I need to make sure I understand what its doing and that its working as it should.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-392148814, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-ILUBfUh9NUDCOnW6Q6fgb56HlOqks5t2FK0gaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
Looking further at the simulation I made more changes. I started simplifying things to better understand the economy dynamic and why sometimes buyers and sellers weren't trading. In the end I think those simplifications should remain as they make sense and result in more stable trade execution and pricing.
The major change was to make buyers places bids that execute as market orders rather than try to determine a bid price. Sellers set ask price based on costs plus a tiny profit, while buyers simply buy at the ask. All buyer/seller code to estimate price bids/asks with "belief" ranges, random effects, and strange behavior isn't used. The lowest asks execute first so buyers get the best available prices, and suppliers with higher costs/prices might not sell if there isn't enough demand, as expected. I also stopped using the code that tried to restrict supply based on price favorability as that was causing problems for no good reason. Now that prices are rationally based on costs rather than randomly generated, everyone just buys what they need and sells what they produce. With the odd randomized stuff no longer mucking things up, the result is more stable prices and better supply/demand and trade execution. And it's much simpler to understand.
A few smaller changes were:
- Use a default production cost on a produced commodity if production costs were zero. This is mainly an initial condition thing due to agents coming into existence with inventory that have no associated costs. Proper relative costs sort themselves out after a few rounds. Price level is largely determined by initial conditions though so what you pick as the default has an impact.
- Agent logic is important as that is the "economy" being modeled. Bad state interaction in the logic can impact everything. For example I've seen states where trade stops because agents can't get food to produce their product but the farmer is also held up waiting on wood which will never come. I solved that by adding a state to the farmer that will produce a single food even if it has no wood.
- I changed the $2 cost punishment for an agent not producing anything to instead be a constant consumption of food each round. Money should not just vanish from the economy, it should move around from agent to agent. So a food requirement is fine, but just pulling out money from the economy is strange and causes unnecessary bankruptcy.
- I put a cap on production in the agent logic so agents stop producing once they have a reasonable level of inventory. With that logic, the code associated with sizing, counting, and limiting inventory elsewhere can probably go away and simplify things further.
The goal of the program is to find relative prices and agent count (supply/demand levels) appropriate for the logic of the simulated economy. I think the above methodology of setting ask prices based on costs and buys made at market does it well and without all the complexity and randomness of the method from the technical paper. Prices are more stable and oversupply of agents is sorted out by bankruptcy as before, but bankruptcy is now accurately a reflection of oversupply and not due to bad ask pricing or trades not executing due to failing bid pricing. Unfortunately the entire "meat" of the technical paper is no longer used, but then it was nonsense to begin with in my opinion (likely because the authors were apparently computer scientists rather than economists--though that's no excuse, I'm a computer scientist rather than an economist also).
Cool! Do you have an updated version of the code I could take a peek at so I could maybe backport the changes? To be honest, I stalled out on this project because I found all these anomalies in the behavior and assumed it was down to my implementation rather than the fundamental theory. I would love to pick it back up if I can get it somewhere sane.
On Sat, May 26, 2018 at 10:00 AM, David [email protected] wrote:
Looking further at the simulation I made more changes. I started simplifying things to better understand the economy dynamic and why sometimes buyers and sellers weren't trading. In the end I think those simplifications should remain as they just make sense and result in more stable execution and pricing.
The major change was to make buyers places bids that execute as market orders rather than try to determine a bid price. Sellers set ask price based on costs plus a tiny profit, while buyers simply buy at the ask. All buyer/seller code to estimate price bids/asks with "belief" ranges, random effects, and strange behavior isn't used. The lowest asks execute first so buyers get the best available prices, and suppliers with higher costs/prices might not sell if there isn't enough demand, as expected. I also stopped using the code that tried to restrict supply based on price favorability as that was causing problems for no good reason. Now that prices are rationally based on costs rather than randomly generated, everyone just buys what they need and sells what they produce. With the odd randomized stuff no longer mucking things up, the result is more stable prices and better supply/demand and trade execution. And it's much simpler to understand.
A few smaller changes were:
- Use a default production cost on a produced commodity if production costs were zero. This is mainly an initial condition thing due to agents coming into existence with inventory that have no associated costs. Proper relative costs sort themselves out after a few rounds. Price level is largely determined by initial conditions though so what you pick as the default has an impact.
- Agent logic is important as that is the "economy" being modeled. Bad state interaction in the logic can impact everything. For example I've seen states where trade stops because agents can't get food to produce their product but the farmer is also held up waiting on wood which will never come. I solved that by adding a state to the farmer that will produce a single food even if it has no wood.
- I changed the $2 cost punishment for an agent not producing anything to instead be a constant consumption of food each round. Money should not just vanish from the economy, it should move around from agent to agent. So a food requirement is fine, but just pulling out money from the economy is strange and causes unnecessary bankruptcy.
The goal of the program is to find relative prices and agent count (supply/demand levels) appropriate for the logic of the simulated economy. I think the above methodology of setting ask prices based on costs and buys made at market does it well and without all the complexity and randomness of the method from the technical paper. Prices are more stable and oversupply of agents is sorted out by bankruptcy as before, but bankruptcy is now accurately a reflection of oversupply and not due to bad ask pricing or trades not executing due to failing bid pricing. Unfortunately the entire "meat" of the technical paper is no longer used, but then it was nonsense to begin with in my opinion.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-392266863, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-F9an8Am5pz2ZFEEeQjSQMsJeC-Rks5t2W36gaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
I'll send you an update of the code today. I think the bid/ask pricing model, inventory management, etc. is now working and simplified to the point where it's less interesting than adding new agents and improving agent logic. I've started messing with agents and their logic, you can ignore those changes as you wish (beyond the fixes mentioned in my last comment). Next I'm thinking about adding lending institutions so new agents would take out loans and pay them back over time rather than just appearing magically bringing new money into the economy. Money shouldn't enter or exit the economy arbitrarily. I''m also adding workers.
If it becomes difficult to add lending and such, I might just throw out the existing agent logic and start from scratch. I'd like to be able to support a more complicated economy... perhaps with more routines than just one process() routine.
Yeah sounds exciting!
It's interesting to tease apart the boundary of how much of the rules of the economy lives in the "world" and how much is actually just the emergent result of however you happen to program your agents -- I figure our projects will probably diverge pretty significantly, but I'm very interested in following along and updating mine a bit. Will you post your code online anywhere, or do you have ambitions other than open source?
On Tue, May 29, 2018 at 12:59 PM, David [email protected] wrote:
I'll send you an update of the code today. I think the bid/ask pricing model, inventory management, etc. is now working and simplified to the point where it's less interesting than adding new agents and improving agent logic. I've started messing with agents and their logic, you can ignore those changes as you wish (beyond the fixes mentioned in my last comment). Next I'm thinking about adding lending institutions so new agents would take out loans and pay them back over time rather than just appearing magically bringing new money into the economy. Money shouldn't enter or exit the economy arbitrarily. I''m also adding workers.
If it becomes difficult to add lending and such, I might just throw out the existing agent logic and start from scratch. I'd like to be able to support a more complicated economy... perhaps with more routines than just one process() routine.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-392876192, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-G2A2DXLU_EKA06hCEnpVJVf0ajYks5t3YxtgaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
I have no ambitions with the code... just learning and hobby fun for me (how sad is it that I find economic simulations fun?). I hadn't expected the project to ever leave my computer, but I guess I could put the project up here with links to you or whatever the license requires.
The license is MIT, so have no restrictions, but it would be neat :)
On Tue, May 29, 2018 at 1:10 PM, David [email protected] wrote:
I have no ambitions with the code... just learning and hobby fun for me (how sad is it that I find economic simulations fun?). I hadn't expected the project to ever leave my computer, but I guess I could put the project up here with links to you or whatever the license requires.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-392879831, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-Ki4Ts97y3IPwjEa9t5atbbttkNvks5t3Y8jgaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
I was hoping you'd uploaded it @Vibr8gKiwi but since I don't see it anywhere could you please also send me a copy [email protected]
thanks
You should have now received a copy knoxx093. By the way, anyone is free to upload the C# project if they want. I claim no ownership, it's just a C# port of larsiusprime's code modified as described above.
Cool, if you don't mind David I might just put that up since people keep asking -- is the version you sent me the latest? Any license you prefer? I'd list you as the porter/author.
And I'll eventually get around to updating the Haxe version, too.
On Tue, Jul 10, 2018 at 6:30 PM David [email protected] wrote:
You should have now received a copy knoxx093. By the way, anyone is free to upload the C# project if they want. I claim no ownership, it's just a C# port of larsiusprime's code modified as described above.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/larsiusprime/bazaarBot/issues/17#issuecomment-403997631, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtG-HfUuLsYJC9JPdLpZFKVBsaV1aDHks5uFTj9gaJpZM4UOYPI .
-- www.fortressofdoors.com -- Games, Art, Design
Hey, looks like I'm a bit late on this, but would someone mind sending me the C# project as well? Couldn't find it up as any of your repos. :( [email protected]
I created a repo BazaarBot2 and uploaded it. It's not as clean as the original... e.g. it doesn't have as nice reporting and I didn't port the json processing. But it contains the fixes described in my comments above. If anyone has questions/comments, or wants to clean it up a bit, please feel welcome.
Also, I've never created a repo here before let alone derived from someone else's project. If I've made some faux pas with renaming it or I'm missing something required by the license or whatever, please let me know (or just fix it).
@larsiusprime can you please update the Haxe repository with changes? I am looking for java port and it will be great if I can compile java sources directly from Haxe.
@DigitalSmile I have reimplemented @Vibr8gKiwi changes in Java. I haven't tested thoroughly.
https://github.com/JeremyWildsmith/bazaarbot-java
I'll hop onto this train as well. I've also translated @Vibr8gKiwi into Unity ECS code.
https://github.com/Kmsxkuse/A_Simulation_Dream
Key changes are reimplementing Json input files and completely removing agent history (mean, min, and max) and replacing it with a flat random number from 50% of needed goods to 150% of needed goods. This change was due to the exponential increase in memory needed as the quantity of agents increased. In a game where I'm envisioning over 10,000 different agents at least, the memory requirement would be astronomical.
Performance in removing agent history also dramatically improved. From ~13 milliseconds a tick to less than 5 ms for about 100 agents.
I've also found that using a liberal amount of "consume input goods up to" values for factory (agents) inputs drastically increases economic stability. Hard coding input good requirements frequently results in factories sitting idle and eventually bankruptcy.
It's a real shame that there is no mathematical function to allow for a moving window calculation of standard deviation like mean does. I might have been able to implement a "present time" calculation of buyer willingness to purchase using previous observed price, previous standard deviation, and current standard deviation...
Wait, I might be able to do that using the current rapid calculation method and lerping the old value to new value by 20%. Use the old value to determine the willingness by 1 - z score and replace old with new score weighted 0.8 * old + 0.2 * new.
Still, at leaves the problem of actually implementing this in a video game.
I am writing a market simulator engine based on the research paper by Doran and Parberry.
Although not a port of BazaarBot, it is largely inspired by it. It is written in Free Pasal, but I plan to port it in other languages (PHP, Python...).
It is far from finished yet. I'm trying to improve the economic stability. So far, I only tested a very basic simulation with only one commodity. I am currently writing the simulation script based on the example of Doran and Parberry.
I have tried to address some of the issues discussed here.
I added a condition in the double auction algorithm to stop the transaction if the seller's price is higher than the buyer's price. I also simplified the agent's stock handling.
The agent's price belief (lower value / higher value) is used as a "trading range" to determine the favorability. So the agent does not need to store a history of all transaction prices for each commodity. I was indeed concerned with the huge amount of memory required. Furthermore, it is how I understand the paper.
The price belief update algorithm is slightly different (still based on the 2010 paper though).
It is named Moneta, after the name of the roman goddess of money.
The project is described here : https://moneta.tuxfamily.org/
Good luck wintermute2021, as I explain above, I think the "belief range" stuff (and most things in the paper) are nonsense. If you actually care about having a functional economy and not going bankrupt, prices aren't "beliefs", they tie to real economic realities like production costs. If you just want to simulate prices with trading ranges for a game, why bother with an underlying simulated economy, just pick a cost and add a random walk factor to it with high/low ranges or something simple.