Before pulling the trigger, and let it trade by itself, let me summarize a bit the approach, so especially those new to these concepts can follow. In time, I have introduced a lot of new terminology, so when something is not clear, please, don't be afraid to request clarifications.
The general idea is that we have "rules" to open and close a trade. These rules are called a "game" and they are specified by the user of the application. When an order is made to "open", we associate to that order a virtual entity called a "player", which maintains in time all the trading information about that order. When the "trade" ends, the player also has finished its life cycle and it is disposed.
Ahead, we will see that there is a lot more with "players", but for now let's stick to the above simplified version of what they are.
By design, players (and therefore the associate trades) can only close when the user's take profit rules are met. There are no rules instead to "take losses". Protection against runaways is provided through a mechanism of "player superposition", controlled by the user rules (the "game"). Player superposition in practice means that we will have both long and short players at the same time, with each team of players providing some "protection" against the runaways on the other side.
Clearly, it's obvious that we can't have total "protection", and most often one side will be "loading up" more than the other, just because we need to take profit and close the trades on the "winning" side.
On top of the player superposition, we may add the so called "layer overlay", which, in general, means we can have for instance two or more layers playing different "games", on the same or different (correlated) instruments.
This is what I wanted to experiment in this thread. So, for instance, we might, for instance, trade ES, with 2 layers. On layer 1 we will trade ES with a long-only-position constraint, and on layer 2 with a short-only-position constraint, and keep collecting the scalps.
There are various ways to define such constraints. A very strict and naive definition would be to allow long only trades on one side and short only trades on the other side. Normally, we do not use such version (which is anyway possible), because that would destroy the superposition logic of the players on the same layer (and therefore conflict with the general logic of the approach).
Instead, we allow both long and short players (trades) on each layer, but we constrain the overall resulting position to be always either long or short on each layer. Again, this cannot provide a total "protection", but it may add up to the hedging capabilities.
The general idea is that we have "rules" to open and close a trade. These rules are called a "game" and they are specified by the user of the application. When an order is made to "open", we associate to that order a virtual entity called a "player", which maintains in time all the trading information about that order. When the "trade" ends, the player also has finished its life cycle and it is disposed.
Ahead, we will see that there is a lot more with "players", but for now let's stick to the above simplified version of what they are.
By design, players (and therefore the associate trades) can only close when the user's take profit rules are met. There are no rules instead to "take losses". Protection against runaways is provided through a mechanism of "player superposition", controlled by the user rules (the "game"). Player superposition in practice means that we will have both long and short players at the same time, with each team of players providing some "protection" against the runaways on the other side.
Clearly, it's obvious that we can't have total "protection", and most often one side will be "loading up" more than the other, just because we need to take profit and close the trades on the "winning" side.
On top of the player superposition, we may add the so called "layer overlay", which, in general, means we can have for instance two or more layers playing different "games", on the same or different (correlated) instruments.
This is what I wanted to experiment in this thread. So, for instance, we might, for instance, trade ES, with 2 layers. On layer 1 we will trade ES with a long-only-position constraint, and on layer 2 with a short-only-position constraint, and keep collecting the scalps.
There are various ways to define such constraints. A very strict and naive definition would be to allow long only trades on one side and short only trades on the other side. Normally, we do not use such version (which is anyway possible), because that would destroy the superposition logic of the players on the same layer (and therefore conflict with the general logic of the approach).
Instead, we allow both long and short players (trades) on each layer, but we constrain the overall resulting position to be always either long or short on each layer. Again, this cannot provide a total "protection", but it may add up to the hedging capabilities.
Last edited: