1m talib breaking candle start #751
Comments
|
But that cannot be the issue. In all other candle sizes the time / date are correct. It only fails in 1 minute. Indeed I tracked the candle start params through the trading advisor and they are all correct. Yet between that and the emit, when backtesting, 1m candle date times become broken. To illustrate how bizarre this behaviour is I have just edited the basetradingmethod.js to write out the readable datetime and the timestamp into new candleprop variables and guess what, now I have the right date time. Ok so not even that works. For some reason all values on 1m candle get broken into something like: 1495029900000 Just so odd. |
|
Further oddness. This is in baseTradingMethod.js: console.log(this.candleProps.stimestamp[this.candleProps.stimestamp.length-1]); This returns correctly. This is in my talib strategy: console.log(this.candleProps.stimestamp[this.candleProps.stimestamp.length-1]); This does not return correctly. What is happening to these values..... |
|
Can you post example code of a strategy that does not work as expected? Also post what version of gekko you are using (the commit hash) please! |
|
Any version of gekko from when I started playing with, circa last 5 months I guess. But to be clear I've just done a fresh install to demonstrate the problem, from the master not dev branch. Put this line in the check function of the gekko default talib-macd strategy: console.log(this.candle.start._i +" - "+ this.candle.start._d); So it reads as: method.check = function(candle) { Use the UI, set talib-macd to 1m candles and default everything and watch the console. This is what I see as an example: 1493906100000 - Thu May 04 2017 14:55:00 GMT+0100 (DST) Note: this happens in any talib related strategy. If I make candles anything other than 1m (in the example below I'm running a 1h candle) this is an example of what i see in the console: 1493625960000 - Mon May 01 2017 09:06:00 GMT+0100 (DST) This is on OSX and Bash on windows and Ubuntu 16.04. As mentioned previously, my goal is the timestamp for each candle as it's stored in the db. |
|
The code that stores candles in a DB is very different code flow, but as I said before:
If you want the unix timestamp of a moment object, use I still don't understand what problem you are having?
If this is the thing you want to do, why are running talib strategies? Just disable the tradingAdvisor so Gekko doesn't even run this code. |
|
I'm completely confused...
If you follow the instructions I've posted above you'll see the issue. Now, if _i and _d cannot be relied upon what you're actually saying is there is candle data which is simply wrong. Which then spawns another couple of questions:
|
You cannot rely on _i and _d to represent anything! These are internal properties of a moment object, that together with other internal properties represent a moment in time. If you want to know the timestamp you should not use _i or _d but |
|
this.candle.start.unix() is broken and does not increment on 1m 1493558100 However, if I put: Into the method.update = function(candle) { it works, I'll test using this rather than check! Thanks for your patience :P |
|
great, so I guess this is solved! |
|
Yep! Thanks |
This is what a non talib output of the variable candle looks like:
{ [Number: 1493917260000]
_i: 1493917260000,
_f: undefined,
_l: undefined,
_strict: undefined,
_isUTC: false,
start:
{ [Number: 1493917320000]
_i: 1493917320000,
_f: undefined,
_l: undefined,
_strict: undefined,
_isUTC: false,
_pf:
Note the second candle Number and _i is 60 seconds after the first. IE this is correct.
However, with a talib indicator you get:
start:
{ [Number: 1493342100000]
_i: 1493342100000,
_f: undefined,
_l: undefined,
_strict: undefined,
_isUTC: false,
_pf:
start:
{ [Number: 1493342100000]
_i: 1493342100000,
_f: undefined,
_l: undefined,
_strict: undefined,
_isUTC: false,
_pf:
Note, Number and _i are identical, there is no sequence. This only happens with talib strategies.
Now, the interesting thing is, if I check the candle variable in tradingAdvisor it is correct. So something is altering that Number and _i to be incorrect, but I can't find where.
Any chance this could be fixed, would really help.
The text was updated successfully, but these errors were encountered: