Gekko: Inaccurate result on Candle and Gekko Indicator

Created on 31 Jan 2018  路  7Comments  路  Source: askmike/gekko

Note: for support questions, please join our Discord server

  • I'm submitting a ...
    [x ] bug report
    [ ] feature request
    [ ] question about the decisions made in the repository

  • Action taken (what you did)
    I made a strategy using EMA and SMA (Gekko indicator), and bring the result on debugging. The result is time, candle close, candle high, candle low, EMA and SMA. I try to compare the result with tradingview and exchanges indicator. I realize the result are different. I worried this bug make not perfect or wrong strategy for everyone.

  • Expected result (what you hoped would happen)
    Have indicator output reliable results where i got from backtesting data, as displayed on the exchange and tradingview.

  • Actual result (unexpected outcome)
    I compared the values with the values given by the candle and my indicator and strategy on poloniex and tradingview with the same parameters for the very same time frames (candles). I realize the candle-data iself (OHCL) and SMA & EMA result from tradingview do not 100% match the candles available in gekko.

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc)

Exchange: Poloniex
Pair: USDT/XRP
Candle Size: 15 min
Indicators: SMA(13), EMA(8)
Using Gekko v0.5.13 and Gekko UI v0.2.0.

Example:
I compare data at 2017-12-13T05:16

My debugging result:
strat

Poloniex:
polo

Tradingview:
tradingview

Strategy:

```// Let's create our own strategy

var log = require('../core/log.js');
var strat = {};

// Prepare everything our strat needs
strat.init = function() {
// your code!
this.requiredHistory = this.tradingAdvisor.historySize;

this.addIndicator('myema', 'EMA', this.settings.diff);
this.addIndicator('mysma', 'SMA', this.settings.timePeriod);

this.bought = 0;

}

// What happens on every new candle?
strat.update = function(candle) {
// your code!
//this.requiredHistory = this.tradingAdvisor.historySize;
}

// For debugging purposes.
strat.log = function() {
// your code!
}

strat.check = function(candle) {

var price = candle.close;

var ema = this.indicators.myema.result.toFixed(6);
var sma = this.indicators.mysma.result.toFixed(6);

var num = Math.abs(sma - ema)
var result = num.toFixed(6);
var diff = 0.02;

var stratBuy = ema > sma && result > diff && this.bought === 0;
var stratSell = ema < sma && result > diff && this.bought === 1;

if(stratSell) {
this.advice('short');
this.bought = 0;

log.debug("SELL");
log.debug("Time: " + candle.start.format())
log.debug("High : " + candle.high);
log.debug("Low : " + candle.low);
log.debug("Close : " + price);
log.debug("EMA: " + ema);
log.debug("SMA: " + sma);
log.debug("===================================");

} else if(stratBuy ) {
this.advice('long');
this.bought = 1;

log.debug("BUY");
log.debug("Time: " + candle.start.format())
log.debug("High : " + candle.high);
log.debug("Low : " + candle.low);
log.debug("Close : " + price);
log.debug("Price : " + price);
log.debug("EMA: " + ema);
log.debug("SMA: " + sma);
log.debug("===================================");

}

}

module.exports = strat;

wontfix

Most helpful comment

@s5m4 @peitrae I've come across the same issue when attempting to calculate heikin ashi candles. The candles in gekko are not correct when I compared against polo and tradingview. It doesn't seem to be a difference in timeframe as s5m4 has mentioned. What it actually seems to be is an incorrect calculation and storing of the 1m candles that gekko uses. Quick overview of what I see in the code is that gekko stores 1m candles not trade history so it calculates these candles on import and then users a batcher to create any size candle you specify that is >1m. Somewhere in this process the calculation is skewing.

You can test this by importing any data from poloniex and creating a test strat that console.logs each candle and then set it to 1m and let er rip. I've confirmed this on BTC/SC on poloniex and tradingview. By testing like this you avoid the possibility of encountering the timeframe difference situation as mentioned by s5m4.

This is a major issue that has stopped me from using gekko entirely as it cannot be relied upon for accurate candles within any timeframe against poloniex.

As a side note, I'm actively working on debugging this issue. If it goes well, I'll send up a pr for extensive testing against all the different exchanges.

All 7 comments

I'm a newby to gekko and coding. How do you implement a custom strategy in the config.js to use this strategy or any other custom strategy? Thanks,

@Cozy35 start here https://gekko.wizb.it/docs - it's all there and relatively beginners friendly!
@peitrae I made very similar experience. at first I thought this is the issue I opened yesterday. :)
one thing to notice is that the gekko candles have different time frame. the exchange candles are always round time intervals, like 07:25 or 12:45 (depending on your candle size of course) while gekko calculates it's own candles depending on when it starts, so it allows for candle times like 7:07 or 11:31. this is why then the gekko candles don't match the exchange candles. something that should be adjustable in my opinion. also the indicator results, which are based on candle data after all, differ because of that. makes it hard to debug indicator results.

OK, I have read it but not sure where to set config.tradingAdvisor.strategy to custom, or how to implement a custom strategy. I have created a custom.js

@s5m4 @peitrae I've come across the same issue when attempting to calculate heikin ashi candles. The candles in gekko are not correct when I compared against polo and tradingview. It doesn't seem to be a difference in timeframe as s5m4 has mentioned. What it actually seems to be is an incorrect calculation and storing of the 1m candles that gekko uses. Quick overview of what I see in the code is that gekko stores 1m candles not trade history so it calculates these candles on import and then users a batcher to create any size candle you specify that is >1m. Somewhere in this process the calculation is skewing.

You can test this by importing any data from poloniex and creating a test strat that console.logs each candle and then set it to 1m and let er rip. I've confirmed this on BTC/SC on poloniex and tradingview. By testing like this you avoid the possibility of encountering the timeframe difference situation as mentioned by s5m4.

This is a major issue that has stopped me from using gekko entirely as it cannot be relied upon for accurate candles within any timeframe against poloniex.

As a side note, I'm actively working on debugging this issue. If it goes well, I'll send up a pr for extensive testing against all the different exchanges.

So, I gave myself a thumbs down, lol. I'm a straight up idiot. The calculations are not wrong I repeat not wrong. The false positive on this issue came from my incorrect understanding of the unix epoch that is set as the candle.start. I was expecting it to be in seconds since poloniex uses epochs at the seconds interval but its actually in milliseconds. This caused me to test candles thinking they were one timeframe but they were actually another. What @s5m4 said is right the issue @peitrae is experiencing is because of the uneven time frame intervals allowed by gekko. If you want check this you can set a custom date range on your backtest so that it starts and ends in an interval you are viewing in poloniex or tradingview.

This issue should probably be closed.

@DrappierTechnologies :'-) that's all cool. so in backtest you can achieve proper candle values by setting the according time frame - I assume it's the "even" values like 12:00 - 12:05 (instead of 12:03 - 12:08, for 5m candles) or 09:00 - 10:00 (instead of 9:27 - 10:27, for 1h candles) - I figured the same in the end. It would be really cool to be able to scedule the start of gekko in live trade or market watcher mode from within gekko. Otherwise you would have to fiddle around a bit with the start to get it right, maybe an external script could do the trick.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If you feel this is very a important issue please reach out the maintainer of this project directly via e-mail: gekko at mvr dot me.

Was this page helpful?
0 / 5 - 0 ratings