Supply vs demand, and what causes a trend.
It is often said that prices move in accordance with supply and demand. That when demand is greater than supply, prices rise, and when demand is less than supply, prices fall. Indeed this appears to be the thinking behind what constitutes a "trend", being, in the case of an up-trend, a sustained period of greater demand than supply, leading to a steady rise in prices.
But I don't think this is quite right, so have an alternative explanation that is similar, but not the same.
The issue with the traditional explanation, in my opinion, is that it explains an up-trend in terms of a sustained period of greater demand than supply. But what is demand? (And what is supply?) In my opinion it is only real demand when a trader places a market order, or when a trader has a limit order in place at the top of the order book about to be executed (in a liquid market). Anything else is for show. Indeed many market participants place limit orders away from the spread and then immediately withdraw them, in order to try to manipulate the market. These don't represent real demand, unless they are placed AT the top.
Therefore at all times in the market, demand must EXACTLY match supply.
So a better way to look at supply and demand, is to say that price, and price changes, are determined by what the price has to be, and has to move to, in order to ensure a continuation of the exact matching of demand, to supply.
Weaver:
I have written some code, which I have named "Weaver" on Microsoft SQL Server to try to simulate this activity.
(SQL Server is a database system. I am a SQL Server developer contractor in the "day job", so understand this technology very well).
It works as follows, with some back-test data I dragged of the API a few months ago:
1. Starting at, say, 2017-07-28 15:00:00.000 UTC. Get from the last close the last price for a single security, say US stock: MPC
Say it was $50.00
2. Advance 1 minute, to 2017-07-28 15:01:00.000
3. Run a stored procedure "pGetActor" that for a range of different types of trader active in the market, what would they do at that point if $50 was still the price. Some would do nothing, some would buy, some would sell. The stored procedure would run with parameter iActorId denoting what type of trader it is supposed to be emulating. The stored procedure would return the positive (if a buy) or a negative (if a sell) volume that would be generated from this trader type in aggregate. Each volume returned is a "actorvolume".
4. The program adds up these actorvolumes generated by the calls of pGetActor, to give the "fVolumeNet" value, the net volume.
If the total is 0 or very close to 0, fix the current price as being the price for this time, because the volumes all match. Advance the clock to the next minute, and go back to 3. for the next minute.
5. If fVolumeNetis greater than zero (or less than zero), then there is some net volume, and according to my theory this means that the price cannot be the current price. So increase (or decrease) the price a single tick, and try again by 3. above with the new price.
With the new price, the actor volumes returned by the calls of pGetActor would also have changed, probably, and therefore adding them up to get fVolumeNet will get a different (probably lower magnitude) value for fVolumeNet.
6. Keep going round the loop, changing the price each time, until the fVolumeNet falls to near zero, or crosses over from positive to negative. This is the price at which volumes are matched, or as good as matched, and according to my theory this is therefore the price that has to result.
Save the price into column cfPriceConclusion and move on to the next minute, and go to 3. above to continue.
Also add up the actorvolumes, but by setting the negative ones of them to positive. And divide by 2. This is VolumeGross, and is the volume that results from the trades that occur at the time from all of the actors.
I've got this bit of code working, with two "Actors", the first "Adam" that always buys at volume 5 regardless of the price, and the second "Brian" who likes to sell at volume: ((@fNumberOfMinutes + 200) *
@Fprice * 0.000301)
(where @fNumberOfMinutes is the number of minutes after the start time).
I ran it for a test period from 2017-07-28 15:00:00.000 to 2017-07-28 17:50:00.000 = 2 hours 50 minutes, and its performance was excellent, completing in under 1 second - showing how good SQL Server is as a technology (it ran pGetActor around 8000 times in that period).
And it returned the result of a price that started high (118.650000), and steadily reduced to a final figure of 53.590000
This is correct because "Brian" earlier on needed a higher price to induce him to trade at sufficiently high enough volume to match that from "Adam". But as time went on Brian become a more active seller, and would do so at progressively lower prices.
So my question to myself is, is there any way this code could be developed such that the different actors had specific trading strategies (e.g. day trader tech analysis, day trader high freq, day trader arbitrager, long term, day trade mean-revert etc) with each strategy coded into pGetActor, with parameters to reflect position sizes, strength of signals required before action etc? Then on a period of back-test data I could run the script many times, each time with different parameters, and find the one that results in price and VolumeGross closely matching the real-world time series data. That would allow me to conclude the number and strength of these market participants in the real world. And with this information I could potentially try to predict future market activity on the assumption that these parameters will be the same in the future.
My initial answer is that it is theoretically possible, but it may be possible to model standardised (parameterisable) behaviour of market participants (actors) only for a small percentage of participants, such as beginners who are trading using technical analysis they have read from a book, and even then their actions are likely to be affected by emotions, departing from the book's instructions.
The rest of the actors are likely to be more sophisticated traders using proprietary models that are not in any text books. And of course many will be using artificial intelligence-led approaches that are also not in a book.
Still it would be a big win if I was able to get it to work, particularly in regard to the closing of positions by day traders at the end of the day; if I was able to deduce that, say, a larger number of day traders than usual had long open positions 5 minutes before the close, then I can be sure that there will be a lot of sell orders coming through in that next 5 minutes.
In all but the simplest cases, to get it right is going to be horrendously complicated, and use a great deal of computing power. Perhaps I could utilize some of the cheap graphics cards being discarded by the cyber currency miners post price collapse, to do some of the heavy processing required.
I expect there must be a simpler more elegant way to do the same thing, or nearly the same thing.