ctubio / tribeca

Self-hosted crypto trading bot (automated high frequency market making) in node.js, angular, typescript and c++
https://127.0.0.1:3000
Other
95 stars 26 forks source link

Change TargetPosition calculation in % #35

Closed Camille92 closed 7 years ago

Camille92 commented 7 years ago

In order to be ready for trading alts with Tribeca, we need to change the formula to calculate the target position in percentage rather than in raw value.

The * 5 is an arbitrary value of the sensibility (reflecting the sensibility we have now on tribeca) In this case it means that a 0.2% difference between Ewma 100 and ewma 200 will put the TargetPosition of 1 meaning all funds minus pdiv should be in crypto. A -0.2% difference will show a target position of -1 meaning all funds minus pdiv should be in fiat!

Related to https://github.com/ctubio/tribeca/issues/31 PS: I didn't try the code but it should work! I mean it's only one line haha

coveralls commented 7 years ago

Coverage Status

Coverage remained the same at 50.94% when pulling a8d6a2c1eecc954549c24726c833e7a4dd903016 on Camille92:patch-13 into 00eccb0e84c4dff815836cf3f3070a06d1d9f3e0 on ctubio:master.

ctubio commented 7 years ago

Hello Camille, im sorry i did a small test and didnt went well: https://jsfiddle.net/m16r7otv/ last test shows "Infinity" and should be some positive value i think

Also im not understanding very good the reason or the expected consequences of this, because anyway this value is reduced to 1 or -1, so it doesnt matter how big it is, the only thing that matter is if is positive or negative in case that is not inbetween 1 or -1. (what is also quite important this values arround 0 inbetween 1 and -1)

You suggest this modification because it still preserves the positive or negative value, so is a transparent change for the current functionality of the application, but will help in the future features?

Maybe can you also do some test at https://jsfiddle.net/m16r7otv/ until you are happy with the new formula? (im sorry i cant help cos i really dont understand the reason or the expected consequences of this)

Thanks for your time'¡

Camille92 commented 7 years ago

Hello I've been trying it during the night on a live bot and it worked as expected :).

Looking at your test, the results are very logical.

I think you need to have a better view of what the EMA are. In this website you can configure it to see the EMA (called here EWMA) 100 and 200. https://bitcoinwisdom.com/markets/bitstamp/btcusd

Those are exponential moving average of the price of bitcoin for the last 100 and 200 minutes. It differs from a simple moving average because it gives more value weight in the calculation of the average to the recent price than the older one.

EMA crossing is a simple an efficient trading strategy that has been around for a while. More about here : http://stockcharts.com/school/doku.php?id=chart_school:trading_strategies:arthur_hill_on_moving_average_crossovers

In Tribeca we use exactly the same system explained there: movcross-coms

In the example for 3Com (COMS)[Coms], a 20/60 EMA crossover system was used to generate buy and sell signals. The plot below the price is the 20/60 EMA differential, which is shown as a percent and displayed using the Percentage Price Oscillator (PPO) set at (20,60,1). The thin blue lines just above and below zero (the centerline) represent the buy and sell trigger points. Using zero as the crossover point for the buy and sell signals generated too many false signals. Therefore, the buy signal was set just above the zero line (at +2%) and the sell signal was set just below the zero line (at -2%). When the 20-day EMA is more than 2% above the 60-day EMA, a buy signal is in force. When the 20-day EMA is more than 2% below the 60-day EMA, a sell signal is in force.

The formula I'm changing is the trigger, or the blue lines in the image. Looking at the code I realized yesterday that the original formula takes into account raw number instead of percentages.

It is very dangerous because it means that if bitcoin falls TargetPosition would be much harder to move. In the other hand the higher the price is the more easily it would be triggered.

Here are some examples using the old formula to trigger a Target position of 1:

(newShort - newLong) / 2.0

Short = 12 Long = 10 (20% diff): (12 - 10) /2 = 1 -> the buy or sell signal is triggered for a 20% difference Short = 102 Long = 100 (2% diff): (102 - 100) / 2 = 1 -> The buy or sell signal is triggered for a 2% difference If Short = 1002 Long = 1000 (0.2% diff): (1002 - 1000 / 2) = 1 -> the buy of sell signal is triggered for a 0.2% difference

Do you spot the problem now ? As the price of bitcoin fluctuates a lot, it is over 6 times easier to trigger a TargetPosition of 1 at $1200 (0.16% to trigger) compared to when the price was $200 in January 2015 (1% difference to trigger).

Lastly your example prove exactly my point: In line 1 and 2 you get exactly the same result with the old formula: while for the first line it's a decrease of 33% and in the second case of 0.1%.

The last line gives infinity because you suppose that the average of the price during the last 200 minutes is 0. Which is first unlikely that we reach 0 and secondly mathematically impossible if the average of this same price during the last 100mn is equal to 2.

Using the formula in % we have a trigger at 0.2% whatever the underlying price is. I'll be watching closely the false breakout in order to be able to give maybe a more accurate number.

I hope I convinced you and you understand better the matter now.

In the future I'll try to think of ways to get a better strategy by maybe using SAR, RSI or MACD.

Camille92 commented 7 years ago

You can even make the % for triggering a 1 target position a configurable variable by changing the formula to:

((newShort 100 / newLong) -100) (1/user_value)

But I don't know if it's very useful for a normal user.

ctubio commented 7 years ago

awesome explanation and links, many many thanks'¡