Dynamic price filter no overlapping deals

d_yo_r · September 25, 2024, 10:25am

The following article explains how the price filters currently work.

Let’s consider a bot with direction long and answer the question, when would the dynamic filter help to prevent deals at the same price?

Only for all prices below the current price that are able to take profit!

But it would fail for all deals above the current price that weren’t able to take profit. At those there could be duplicate deals. How many?

Let’s assume we start a long bot with dynamic filter smaller than take profit.

We start at with B(0, 1). The price doesn’t reach TP(0, 1).
Instead it reverses to B(-1, 1). The price goes up again to TP(-1, 1).
The price also reaches B(0, 2). But again we don’t reach TP(0, 2).

This could continue until the maximum amount of simultaneous deals is reached.

But as soon as we pass TP(0, *) all open deals B(0, *) at this level would be closed.

Deals below would always be closed when reaching their TP.

For deals above their could also be several deals per level with the same argument if the price first goes up to e.g. B(10,*) and down from there again with the same movements at each level as I described them for B(0, *).

Therefore it would be required for the bot to check whether there’s already an open deal in the price range. As explained above therefore it would probably be enough to remember one price per pair the price of the latest open deal which take profit wasn’t reached before.

d_yo_r · September 25, 2024, 12:31pm

Just to add a more textual description e.g. for a long bot.

1. deal opens but does not reach TP
1. deal opens below with dynamic price filter
1. deal takes profit
1. deal opens above the closed 2. deal at the level of the 1. deal, because the filter refers to the price of the 2. deal.

And this can repeat at different levels, resulting in stacked deals at a bunch of levels.

d_yo_r · September 26, 2024, 12:31pm

Let’s do a quick check thought what would happen if we currently only used either over or under.

If we have a long bot and use under. Independently of the relation between minimum deviation and take profit and what Price source we use, deals can always only open under. Of course, if the price decreases there can be several deals above the current price. But the bot won’t open new deals in that range if the price increases again.

The opposite is true for “short” bot over.

Let’s consider the missing cases.

If we have a long bot and use over. Independently of the relation between minimum deviation and take profit and what Price source we use, deals can always only open over. Of course, if the price increases there can be several deals below the current price if those hasn’t taken profit yet. But the bot won’t open new deals in that range if the price decreases again.

The opposite is true for “short” bot under.

That is the issue only occurs if both over and under are used at the same time. And for that is this feature request.

What could be checked is whether it would be enough to separate over and under but this would result in a bigger and bigger gap where no trades would be started.

d_yo_r · September 26, 2024, 5:43pm

As @hunterwhalehunter reminded correctly, the effect of stacked orders at price levels, when using a combined over and under, would be the stronger the closer the percent change and it’s reversal are but would weaken for bigger differences as here:

-20% = 0.8
0.8^(-1) = 1.25 = +25%.

d_yo_r · September 27, 2024, 6:24am

Let’s add a table that shows one of the many possible results of a combined over and under for different percentages as it is currently implemented.

The first row of all columns starts at

row(0) = 100

The next rows contain the values

row(2a + 1) = row(2a)     * (1 - p)
row(2a)     = row(2a - 1) * (1 + p)

for integer a >= 1, where the value in the function brackets determines the row of the value.

Row	±1% ↑1.01 ↓0.99	±2% ↑1.02 ↓0.98	±5% ↑1.05 ↓0.95	±10% ↑1.1 ↓0.9	±20% ↑1.2 ↓0.8
0	100.00	100.00	100.00	100.00	100.00
1	99.00	98.00	95.00	90.00	80.00
2	99.99	99.96	99.75	99.00	96.00
3	98.99	97.96	94.76	89.10	76.80
4	99.98	99.92	99.50	98.01	92.16
5	98.98	97.92	94.52	88.21	73.73
6	99.97	99.88	99.25	97.03	88.48
7	98.97	97.84	94.29	87.33	70.79
8	99.96	99.84	99.01	96.07	84.95
9	98.96	97.76	94.06	86.46	67.96
10	99.95	99.80	98.76	95.11	81.55

If we would go into the other direction first we would get:

row(2a + 1) = row(2a)     * (1 + p) 
row(2a)     = row(2a - 1) * (1 - p)

Row	±1% ↑1.01 ↓0.99	±2% ↑1.02 ↓0.98	±5% ↑1.05 ↓0.95	±10% ↑1.1 ↓0.9	±20% ↑1.2 ↓0.8
0	100.000000	100.000000	100.000000	100.000000	100.000000
1	101.000000	102.000000	105.000000	110.000000	120.000000
2	99.990000	99.960000	99.750000	99.000000	96.000000
3	100.989900	101.959200	104.737500	108.900000	115.200000
4	99.980001	99.920016	99.500625	98.010000	92.160000
5	100.970100	101.920000	104.475656	107.811000	110.592000
6	99.970003	99.880048	99.251873	97.029900	88.473600
7	100.950401	101.881600	104.214375	106.732890	105.168320
8	99.960006	99.840096	99.003744	96.059601	84.934656
9	100.930900	101.843200	103.953925	105.665561	100.921587
10	99.950010	99.800160	98.756234	95.099005	81.537270

d_yo_r · September 27, 2024, 9:44am

Let’s instead consider the current minimum deviation to become the required change x%.

Then we have the following formulas for a long bot.

row(2a + 1) = row(2a)     * (1 + p)
row(2a)     = row(2a - 1) / (1 + p)

and

Row	1% ↑1.01=+1% ↓1/1.01=-0.99%	2% ↑1.02=+2% ↓1/1.02=-1.96%	5% ↑1.05=+5% ↓1/1.05=-4.76%	10% ↑1.1=+10% ↓1/1.1=-9.09%	20% ↑1.2=+20% ↓1/1.2=-16.67%
0	100.000000	100.000000	100.000000	100.000000	100.000000
1	101.000000	102.000000	105.000000	110.000000	120.000000
2	100.000000	100.000000	100.000000	100.000000	100.000000
…

If the take profit is smaller than the deviation, the first deal would be closed before the next deal starts. On a reversal the next deal could start at 100 without creating a duplicate at that level.

If the deal would go into the other direction first we would get:

row(2a + 1) = row(2a)     / (1 + p)
row(2a)     = row(2a - 1) * (1 + p)

resulting in:

Row	1% ↑1.01=+1% ↓1/1.01=-0.99%	2% ↑1.02=+2% ↓1/1.02=-1.96%	5% ↑1.05=+5% ↓1/1.05=-4.76%	10% ↑1.1=+10% ↓1/1.1=-9.09%	20% ↑1.2=+20% ↓1/1.2=-16.67%
0	100.000000	100.000000	100.000000	100.000000	100.000000
1	99.009901	98.039216	95.238095	90.909091	83.333333
2	100.000000	100.000000	100.000000	100.000000	100.000000
…

If the take profit is smaller than the deviation, the first deal wouldn’t be closed and also the second deal would be still open. On the third deal, the second deal would be closed, while we would recognize that there already is a deal at that price 100 and wouldn’t open a new one at this level.

On the opposite for a “short” (respective real short) bot it would look like that

row(2a + 1) = row(2a)     / (1 - p)
row(2a)     = row(2a - 1) * (1 - p)

Row	1% ↓0.99=-1% ↑1/0.99=+1.01%	2% ↓0.98=-2% ↑1/0.98=2.04%	5% ↓0.95=-5% ↑1/0.95=+5.26%	10% ↓0.9=-10% ↑1/0.9=11.11%	20% ↓0.8=-20% ↑1/0.8=25%
0	100.000000	100.000000	100.000000	100.000000	100.000000
1	99.000000	98.000000	95.000000	90.000000	80.000000
2	100.000000	100.000000	100.000000	100.000000	100.000000
…

If the take profit is smaller than the deviation, the first deal would be closed before the next deal starts.

If the deal would go into the other direction first we would get:

row(2a + 1) = row(2a)     * (1 - p)
row(2a)     = row(2a - 1) / (1 - p)

Row	1% ↓0.99=-1% ↑1/0.99=+1.01%	2% ↓0.98=-2% ↑1/0.98=2.04%	5% ↓0.95=-5% ↑1/0.95=+5.26%	10% ↓0.9=-10% ↑1/0.9=11.11%	20% ↓0.8=-20% ↑1/0.8=25%
0	100.000000	100.000000	100.000000	100.000000	100.000000
1	101.010101	102.040816	105.263158	111.111111	125.000000
2	100.000000	100.000000	100.000000	100.000000	100.000000
…

If the take profit is smaller than the deviation, the first deal wouldn’t be closed and also the second deal would be still open. On the third deal we would recognize that there already is a deal at that price 100 and wouldn’t open a new one at this level and if the price would go up again also not at 101.01…

d_yo_r · September 27, 2024, 2:47pm

Notice how we had to change the percent change depending on the direction:

long

(1 + p)

“short”/short

(1 - p)

This was necessary to create a geometric grid for each direction.

d_yo_r · September 27, 2024, 10:27pm

In this message I assumed that currently the deviations are calculated geometrical ly. But if I remember the Combo bot Mini grid which currently are only arithmetic.

If so the current result would look like that. We start with 1000 and a deviation of 1%, that is a step width of 10 and the price levels always 10 apart of each other. The percentage between prices would be smaller and smaller in uptrends and the opposite is true for downtrends.

aressanch · September 28, 2024, 4:06am

Can I have the elevator pitch version of your suggestion? I asked chatgpt to summarize this thread but it couldn’t

Rossano · September 28, 2024, 4:13am

In a few words - add the option to track the set deviation so it doesn’t open new deal on the same price - as discussed with you and @maksym.shamko atm when you have over and under or avg price as starting condition the deals overlap on the same price - with this add-on you can chose to don’t overlap if a deal is already opened on that price

d_yo_r · September 28, 2024, 6:51am

Not only. Depending on the current implementation, which I of course can only make guesses about, it would help to change how over and under are calculated to make sure that the levels build a geometric grid where the max required change to break-even is at most the current minimum deviation.

This probably would have to be done differently for long and short bots. With that a combined over and under would use the exact same levels in both directions and could easily identify, whether another open deal started at that price.

Further we would prevent the effect of orders being placed between previous order levels. And in contrast to adding the level check to the current calculation, we wouldn’t get gaps between previous levels where the deal under was closed and the open deal above prevents adding a deal in between the closed and open deal.

All those calculations are currently based on the assumption that we use entry price. For average price I probably have to think about above logic again whether it would still hold. But I am afraid that it may become trickier then, because the average price moves into the direction of the current price when adding funds and away from it when reducing funds. Because of that we cannot know in advance where the price level of the next deal will be. But at least, with max required change and thorough checks for open deals at those levels we could be sure to build a geometrically spaced levels from there. But of course, this wouldn’t prevent that the average price of other deals moves into those levels later.

d_yo_r · September 28, 2024, 12:20pm

(Remark: With this max required change over and under as deviation based on a deal’s average price and available instead of deviation for safety orders of a deal, possibly my required change range idea could be easier to setup in a bot.)