Optimizer data Question

[GJF1]

With the backtesting optimizer, can the values to be changed be arrays of different data lengths? The docs show this example where they are all the same length with 3 data elements each to be used by the optimizer:

[kernc]

The array lengths, in fact, differ:

>>> len(range(10, 110, 10))                                                                
10
>>> len(range(20, 210, 20))                                                                
10
>>> len(range(15, 35, 5))                                                                  
4
>>> len(range(10, 25, 5))                                                                  
3

As the API reference for Backtest.optimize() says:

Additional keyword arguments represent strategy arguments with list-like collections of possible values.

I think the conundrum here revolves around the use of range(), a Python built-in. Basic Python questions like that are surely out-of-scope here, pointing to StackOverflow as the better-suited venue. 👈 😁

[GJF1]

Your docs say: [image: image.png] This causes realtime trading of an algo to trade very differently than end of bar backtests only. Any plans to enable 1 minute bars of close data to act like one minute ticks within long bars in this framework, where 1 minute bars are not realtime tick data, but a very good approximation of ticks so that trade signals could occur within the long 1, 2 hour or day long bars during a backtest calculation?

…

On Fri, Sep 11, 2020 at 4:28 PM kernc ***@***.***> wrote: The array lengths, in fact, differ: >>> len(range(10, 110, 10)) 10 >>> len(range(20, 210, 20)) 10 >>> len(range(15, 35, 5)) 4 >>> len(range(10, 25, 5)) 3 As the API reference <https://kernc.github.io/backtesting.py/doc/backtesting/backtesting.html#backtesting.backtesting.Backtest.optimize> says: Additional keyword arguments represent strategy arguments with list-like collections of possible values. I think the conundrum here revolves around the use of range(), a Python built-in <https://docs.python.org/3/library/stdtypes.html#range>. Basic Python questions like that are surely out-of-scope here, pointing to StackOverflow <https://stackoverflow.com> as the better-suited venue. 👈 😁 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBVCQGFMJSVAUAYQOMUNFLSFKQB7ANCNFSM4RINCTPA> .

[kernc]

to act like one minute ticks

The attached image didn't get through, and I have no idea what this means. The bars granularity is up to the user: you can have 1-minute bars or you can (supposedly; untested) even have 1-tick bars (with O=H=L=C).

[GJF1]

The graphic just quoted your docs saying there is no way to backtest trade signals within a bar, but they only occur at the end of a bar in the backtest. This behavior is very different than trading realtime tick data. My pinescript algo trades very different live on Tradingview vs their backtests due to the end of bar issue. Here is a detailed post that documents how very different the two results are and why: https://kodify.net/tradingview/strategy-settings/calc-tick-backtest-difference/ I am trying to backtest my TV algo on backtester.py to try and get results closer to how it trades off live tick data and also use your optimizer to tune 6 parameters in my volume/price/trend algo to maximize return. My thought was if there was a way that you could have 60 one minute bar close prices assembled serially into a one hour bar calc in the backtest, you would have a very unique and valuable backtester because it would test results much closer to how algos trade live. Gordon

…

On Fri, Sep 11, 2020 at 5:20 PM kernc ***@***.***> wrote: to act like one minute ticks The attached image didn't get through, and I have no idea what this means. The bars granularity is up to the user: you can have 1-minute bars or you can (supposedly; untested) even have 1-tick bars (with O=H=L=C). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBVCQELTK3Q3776FM4ITPLSFKWCNANCNFSM4RINCTPA> .

[kernc]

I'm aware of indicator repainting on TradingView, the likely culprit for your strategy not performing as well on live trading.

have 60 one minute bar close prices assembled serially into a one hour bar calc

That's also my view of how the markets work. If you ensure none of your indicators look ahead of time, you should get closer to the performance you expect. 👍

[GJF1]

OK thx for your help today. G

…

On Fri, Sep 11, 2020 at 5:54 PM kernc ***@***.***> wrote: I'm aware of indicator repainting <https://www.tradingview.com/pine-script-docs/en/v4/essential/Indicator_repainting.html> on TradingView, the likely culprit for your strategy not performing as well on live trading. have 60 one minute bar close prices assembled serially into a one hour bar calc That's also my view of how the markets work. If you ensure none of your indicators look ahead of time, you should get closer to the performance you expect. 👍 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBVCQF5TVVITVN4FSKJXOTSFK2EDANCNFSM4RINCTPA> .

[GJF1]

If I had access to historical stock tick data, would it be possible to use it with backtesting.py or would it take significant modifications to get it to work? thx Gord

…

On Fri, Sep 11, 2020 at 9:41 PM Gordon Foster ***@***.***> wrote: OK thx for your help today. G On Fri, Sep 11, 2020 at 5:54 PM kernc ***@***.***> wrote: > I'm aware of indicator repainting > <https://www.tradingview.com/pine-script-docs/en/v4/essential/Indicator_repainting.html> > on TradingView, the likely culprit for your strategy not performing as well > on live trading. > > have 60 one minute bar close prices assembled serially into a one hour > bar calc > > That's also my view of how the markets work. If you ensure none of your > indicators look ahead of time, you should get closer to the performance you > expect. 👍 > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#141 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AJBVCQF5TVVITVN4FSKJXOTSFK2EDANCNFSM4RINCTPA> > . >

[kernc]

As I said, OHLC format is mandatory, but other than that:

The bars granularity is up to the user: you can have 1-minute bars or you can (supposedly; untested) even have 1-tick bars (with O=H=L=C).

[GJF1]

OK thx! That is an interesting idea to use the OHLC

…

On Sat, Sep 12, 2020 at 1:26 PM kernc ***@***.***> wrote: As I said, OHLC format is mandatory, but other than that: The bars granularity is up to the user: you can have 1-minute bars or you can (supposedly; untested) even have 1-tick bars (with O=H=L=C). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJBVCQGWWZO3MRGBGTNTPG3SFPDORANCNFSM4RINCTPA> .