@run-out I don't think I would call this a small error. If I use a 100 EMA like I'm trying to it's 15.1 on 12/31/2019 compared to 14.35. That's a massive difference and will cause massively different results. If these four values are used to calculate the ema

2019-08-08T00:00:00, close: 16.91, ema: nan

2019-08-09T00:00:00, close: 17.97, ema: nan

2019-08-12T00:00:00, close: 21.09, ema: nan

2019-08-13T00:00:00, close: 17.52, ema: 18.37

Shouldn't it be the same from any source as long as the alpha is the same?

@ab_trader What initial value would be different? Wouldn't the initial value be 8/8 no matter what?

Re: Somehow EMA is slightly off

So this has been very frustrating, something so simple just off by a hair.

I tried this using an EMA with period 2, and then kept incrementing up. The EMA kept being correct. I was looking at the last candles out of around 300. When I went from 75 to 100 the number was very slightly off. 0.01. As I scanned down it got more a more off of the number from trading view. (also verified with yahoo finance).

I put it back to 4 and went to the very beginning and sure enough the ema on the first available candle is off and it gets better as you get further from the first candles.

2019-08-08T00:00:00, close: 16.91, ema: nan

2019-08-09T00:00:00, close: 17.97, ema: nan

2019-08-12T00:00:00, close: 21.09, ema: nan

2019-08-13T00:00:00, close: 17.52, ema: 18.37, real: 18.68

2019-08-14T00:00:00, close: 22.1, ema: 19.86, real: 20.05

2019-08-15T00:00:00, close: 21.18, ema: 20.39, real: 20.50

2019-08-16T00:00:00, close: 18.47, ema: 19.62, real: 19.69

2019-08-19T00:00:00, close: 16.88, ema: 18.53, real: 18.56

2019-08-20T00:00:00, close: 17.5, ema: 18.12, real: 18.14

2019-08-21T00:00:00, close: 15.8, ema: 17.19, real: 17.20

2019-08-22T00:00:00, close: 16.68, ema: 16.99, real: 16.99
# From here on it's correct

I know if I suggest that it might be a bug the user/creator backtrader will come for my throat :)
So it's probably something with the data somehow. So what the hell is going on here? Driving me crazy.

There's no way I'm not doing something real dumb and this is going to be a simple answer..

I'm trying to use the 100 period EMA of the VIX in my strategy. non trading tickers are always the first data to be added.

("non_trading_tickers", ["VIX"])
...
self.non_trading_ticker_data = self.datas[0:len(self.p.non_trading_tickers)]
...
self.vix_index = [i for i, d in enumerate(self.non_trading_ticker_data) if d._name == "VIX"][0]
self.non_trading_ema["VIX"] = bt.ind.ExponentialMovingAverage(self.non_trading_ticker_data[self.vix_index], period=100)

I'm looking at the VIX on trading view on CBOE and through yahoo finance (where I'm getting the data). When I look at May 29th 2019 I see the vix 100 period EMA at 15.9 on both data sources, when I output the 100 period EMA on that date I get

self.log([self.non_trading_ema["VIX"][0], self.non_trading_ema["VIX"][-1]])
self.log(self.non_trading_ticker_data[self.vix_index].close[0])

2019-05-29T00:00:00, 15.682198154811706
2019-05-29T00:00:00, 17.899999618530273

15.68 as you can see above. The close is 0.0000001 off but there's no way slight floating point errors would cause a difference of 0.22. I've also spot checked other closes and they are all right (minus floating point error)

I believe I've given enough details, if you want more feel free to ask

When I try to use 1 month of data on 100 stocks on 5 minute intervals the whole thing is done in about 60s. Bump that up to 2 months and it was hanging for ~30 mins before I killed it. When I killed it I got this error.

Traceback (most recent call last):
  File "C:\Users\Dane\AppData\Local\Programs\Python\Python37\lib\site-packages\pandas\core\arrays\datetimes.py", line 2081, in objects_to_datetime64ns
    require_iso8601=require_iso8601,
  File "pandas\_libs\tslib.pyx", line 364, in pandas._libs.tslib.array_to_datetime
  File "pandas\_libs\tslib.pyx", line 447, in pandas._libs.tslib.array_to_datetime
ValueError: Tz-aware datetime.datetime cannot be converted to datetime64 unless utc=True

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pandas\_libs\tslibs\timezones.pyx", line 176, in pandas._libs.tslibs.timezones.get_utcoffset
AttributeError: 'tzoffset' object has no attribute '_utcoffset'

After doing some more investigation, when I run for two months on a different timeframe it's fine. I was running this on 10-02-2020 to 12-02-2020. I used only 1 stock and then started reducing the time frames. 10-02 to 10-15 is fast (0.6s) 10-20 to 11-02 takes 6.8s.

I'm using polygon.io for my data. On the first run any time frame is fast.

url = self.base_url + f"/v2/aggs/ticker/{ticker}/range/{mult}/{timespan}/{from_}/{to}?unadjusted={unadjusted}&sort=asc&limit={limit}&apiKey={self.key}"
...
key_changes = []
for r in res_json["results"]:
    dt = self._transform_ts_to_dt(r["t"])
    if dt.time() < time(16, 0, 0) and dt.time() >= time(9, 30, 0):
        key_changes.append(
            {"Open": r["o"], "High": r["h"], "Low": r["l"], "Close": r["c"], "Volume": r["v"], "Datetime": dt}
        )
new_df = pd.DataFrame(key_changes).set_index("Datetime")

return new_df
...
# then write to csv
ticker_data.to_csv(open(file_name, "w+"))

If I already have the daterange for a particular stock I do this

file_data = pd.read_csv(file_name, index_col="Datetime", parse_dates=True)

Finally I add my data like so

data = PandasExtra(dataname=ticker_data, tz=pytz.timezone('US/Eastern'), timeframe=bt.TimeFrame.Minutes, compression=5, sessionstart=datetime.time(9, 30, 0), sessionend=datetime.time(16, 00, 0))
data.addfilter(bt.filters.SessionFilter(data))
data.addfilter(bt.filters.SessionFiller(data, fill_vol=0))

added_data = True
cerebro.adddata(data, name=ticker)

I've looked at both spreadsheets. I can't see any difference. Since I'm using session filler I checked how many intervals volume was 0 and it was about the same.
Attached are both the 10-02 to 10-15 spreadsheet which runs well and the 10-20 to 11-02 spreadsheet which runs slow. Nvm apparently I don't have the privileges to attach documents. If you think you need that could I get those privileges? I'll paste a few lines here.
Good data

Datetime,Open,High,Low,Close,Volume

2020-10-02 09:30:00-04:00,17.83,18.0622,17.7659,18.0622,7782

2020-10-02 09:35:00-04:00,18.0101,18.12,18.0101,18.1,3254

2020-10-02 09:40:00-04:00,18.12,18.18,18.12,18.15,1529

2020-10-02 09:45:00-04:00,18.21,18.25,18.21,18.25,800

2020-10-02 09:50:00-04:00,18.1,18.19,18.08,18.19,2242

Apparently bad data

Datetime,Open,High,Low,Close,Volume

2020-10-20 09:30:00-04:00,15.155,15.28,15.151,15.215,5200

2020-10-20 09:35:00-04:00,15.28,15.335,15.26,15.32,1902

2020-10-20 09:40:00-04:00,15.3475,15.39,15.345,15.35,3221

2020-10-20 09:45:00-04:00,15.37,15.54,15.31,15.54,6953

2020-10-20 09:50:00-04:00,15.41,15.5,15.34,15.35,2845

2020-10-20 09:55:00-04:00,15.34,15.46,15.34,15.46,6611

2020-10-20 10:00:00-04:00,15.46,15.49,15.44,15.49,3368

2020-10-20 10:10:00-04:00,15.49,15.49,15.48,15.48,720

Thanks

@ab_trader I believe that was it, I looked at the source code and it looks like calling cancel from the order object simply marks the status as cancelled and doesn't actually cancel the order with the broker. Which was very confusing because of course it wasn't giving an error and when I was printing out the orders they were marked cancelled, but the broker didn't know that.

@ab_trader @run-out
Do I need more than this?

d.orders["limit"].cancel()
d.orders["stop"].cancel()

Those are my orders, I confirmed the stop went into a cancelled state. Then it went into a completed state as it executed 10 minutes later

After my limit is reached I sell half of my position and I open a trailing stop at that point for the rest of the amount to "let it ride". I'm using a strategy on 5m intervals so I'm cancelling any orders at the end of the day (30 mins before). The timeframe of what is happening is that a stock's price hits the limit and half of the position gets sold. Then it hits 3:30 and the other half gets sold and I'm cancelling my trailing stop loss. 10 minutes later my trailing stop loss gets triggered even though it should be cancelled? It then shorts the stock which is then immediately bought back 5mins later since it's past 3:30. Is there some type of issue cancelling trailing stops? Or am I misunderstanding something?

@techydoc That's almost what I want. In the stochastic it should contain a "slowD" and a "slowK" or something of that nature. A d and a k value. The k is the default, how do I get the k.

Also, is this documented somewhere? There's this documentation but it doesn't contain any details of what these objects actually contain which is very frustrating. https://www.backtrader.com/docu/indautoref/

I'm building a list in my init of my strategy like so

for d in self.datas:
            self.stoch_lst.append(bt.ind.Stochastic(d, period=14, period_dfast=3, safediv=True))

Really simple and it's working.

Then in my next how do I get the d period? I'm accessing the k value like so

self.stoch_lst[i][0]

and then using it without getting the 0 index for comparisons, but how would I get the d value from the stochastic? Or any other indicator that produces more than one line.

I'm sure this is really simple but I can't find it on the docs and my google searches have came up empty somehow.
Thanks.