Alex, would you care to give a more specific problem statement for the goods distribution? You mentioned in your blog post you had written a technical description of your second (current) solution as well -- perhaps you still have this somewhere? I'm asking because I have a fair bit of experience with such problem solving, and I'd be interested to see if I could help out -- I'd love it if I could
I don't have that anymore - it was part of the blogpost but was edited out.
Specifically: What is the optimisation problem you want to solve? Are the accepted deals carried out by transport fleets, which can be disturbed? (And what happens in such a case? Who's responsible for the goods during transport?) Can you be a bit more specific on the allotted CPU resources as well? Implementation in Java, I suppose?
Basically - the markets are in a (mostly) fully-connected, bidirected graph. Edge weights represent the overhead for a trade between the two markets - hostile factions, distance, etc. Specifically, the weight is a multiplier for the price. E.G. if one market is buying food that another is selling 20 credits per unit, and the edge weight is 1.5, the actual cost to the first market is 30 credits per unit.
Prices are based on stockpile compared to max(local demand, local supply), roughly.
The deals are carried out directly by the algorithm; there are transport fleets that spawn based on the deals, and them being destroyed feeds back into connection weights.
The main desired property is that there are no profitable trades remaining to be made, the prices of things being balanced across all connections. E.G. the price market A is willing to pay for food is less than the price at which all connected markets are selling food at, times the relevant edge weight. Not meeting this 100% is fine, just something the sim aims for.
There are complications, though - for example, a "stability" rating for each market, with more stable markets being able to pay more, and charging more. Stability is in turn raised by being able to meet demand, and exports, but lowered by imports. Another is being able to support transitive trade - i.e. market A sells to B sells to C, when the edges A-B and B-C combined are cheaper than A-C directly, or A-C directly just doesn't exist.
CPU-wise, it's... well, that's hard to quantify. As a ballpark, the new version takes maybe 5-6 seconds (fully dedicated to running the economy) to more or less stabilize, on my dev pc. It should also be able to run incrementally, though; if an iteration takes more than half a second it's quite a bit too much. Obviously CPU-dependent, hence "hard to quantify".
I also wonder if you considered an economy where the markets are more passive, and only set their prices based on current stockpiles, and where merchants -- independent or faction-owned -- drive the market through "buy low, sell high"? This has been rather successfully implemented in e.g. the X3 series.
I think that boils down to much the same thing as this new version is doing, as both favor making trades across higher price gaps first.
(I appreciate your curiosity/desire to help, but I'd hate for you to spend a lot of time on it. From my perspective, the new approach pretty much solves the problem!)