More refactoring

[DigitalSmile]

The code seems to be pretty bad in architecture... I can make an effort to build more stable, readable and expandable architecture.

[DigitalSmile]

I did some implementation of new Market2. Can you have a look and tell me your thoughts?
https://github.com/JeremyWildsmith/bazaarbot-java/tree/major-refactoring2

It is a bit dirty right now, but shows the direction of changes I am making. There is no statistics yet and no price negotiation.

[JeremyWildsmith]

Yeah I'll take a look; thanks!

[JeremyWildsmith]

Okay I've taken a look. Overall, it looks much cleaner and I like it. Two pieces of feedback though:

1. Statistics / History -> It would be nice if this wasn't directly implemented into the Market class. I feel like history should be a totally separate class, and we can observe events in the market via a listener instance and record those events into history. Ofcourse, the obstacle here is that history also appears to be a fundamental function of the Market class (ie,"getAverageHistoricalPrice") So maybe market can keep only an internal limited lookback history of the market - but it shouldn't be the ultimate source for history in the market.

Another issue with history is that it can cause performance issues. It would be better to keep a limited history in the market (say up-to a specified lookback parameter; like we are doing with agents) Then thorough history (for purposes of collecting market statistics etc etc) can be obtained in a separate class by observing market events. That way, if you want to study your market you can plugin a memory expensive history keeper; but if you're developing a game with over 2000 agents, you can simply not create or plugin the history module and keep performance optimal.

All this basically ties into not having functions like "getMostProfitableAgentClass" or "getDearestGood" ir "getHottestGood" since those functions should probably be more dedicated to a history class that observes market events.

Just an idea, but I am open to better alternatives.

2. Round based simulation:
   At the very least, I think simulate should be replaced with step(), which only steps one round. Basically, the logic for how many steps to do etc should be done by the user. It makes the code easier to understand. Then the user can just wrap the step() with a for loop or whatever.

for(int x = 0; x < 20; x++) market.step()

Edit: On second thought, maybe we could have both step() and step(x rounds)

But, more on this note: I don't really like the idea of round based simulations. Of course, I think that it simplifies the market simulation but I don't think its really flexible. I am open for different ideas on this though for sure; but I'll explain some ideas I have for it:

• Logic for our agents (consumption, production of goods, creation of bids/asks etc) should all be a function of time. I.e, produces 10 wood a second etc etc. However real-world time translates into the simulation is up to the user of the library. For our purposes, we can take the time argument in terms of seconds. So all agents could have an update function that gets called at fixed intervals (lets say, 10 milli-seconds).

• The market can attempt to resolve offers; when an offer is outstanding for longer than x seconds, it gets rejected. This ties back into making offer resolution occur at intervals of time rather than "rounds"

[DigitalSmile]

Thanks for feedback. I totally on what you say about history and statistics, I just did not spend time to develop the code on this. Of course there will be no instances of full history in market, no doubts.

As for the steps, it was just a boilerplate code, that simplifies the testing and shows the idea. I am also thinking rounds are not best fit to the logic. Your points about functions over time and resolution of offers based on expiration dates are valid, I would try both of them and we will see what is better.
NB - by this point of development we are probably near the multi-threading muddy waters. That is also a thing for consideration, let's keep in mind, that real apps usually are using threads and/or coroutines.

Thanks for feedback, I will go on with refactoring then.
P.S. Made a slack channel for an easier chat, feel free to join - https://join.slack.com/t/bazaarbot/shared_invite/enQtNzI2NzMzNTM3NDQxLTExMjFlMzJhN2Y4MTRkOTExMDcyMzkzZWYzMDI2MTdlMDk3ZDU2Yjc1ZDJkNDk5NjYzY2IzMjVkMDkwMzYxZjc

[DigitalSmile]

@JeremyWildsmith I have created some kind of statistics, price negotiation and history. I wrote very simple JMH tests to control performance. Right now it is poor, I am working on improving it (I know where I made mistake and what to improve)... Please, have a look.

As for the events and not step based simulation, that is on my list in next couple of days.

[guillaume-alvarez]

Thanks for the effort!

Do you still plan to merge the refactor?
Maybe you could already merge what was done then try to improve step by step?

[DigitalSmile]

Let me review the code once again to decide whether it is ready for the merge. Thanks for reminder.

[DigitalSmile]

I have updated the major-refactoring2 branch with latest changes. Can someone review and say if it okay with everyone to merge with master?

[guillaume-alvarez]

Thanks for your work :-)