Closed GJF1 closed 4 years ago
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. :point_left: :grin:
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 notifications@github.com 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 https://github.com/kernc/backtesting.py/issues/141#issuecomment-691338861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBVCQGFMJSVAUAYQOMUNFLSFKQB7ANCNFSM4RINCTPA .
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).
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 notifications@github.com 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 https://github.com/kernc/backtesting.py/issues/141#issuecomment-691350998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBVCQELTK3Q3776FM4ITPLSFKWCNANCNFSM4RINCTPA .
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. :+1:
OK thx for your help today.
G
On Fri, Sep 11, 2020 at 5:54 PM kernc notifications@github.com 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 https://github.com/kernc/backtesting.py/issues/141#issuecomment-691358103, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBVCQF5TVVITVN4FSKJXOTSFK2EDANCNFSM4RINCTPA .
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 gord.foster@gmail.com wrote:
OK thx for your help today.
G
On Fri, Sep 11, 2020 at 5:54 PM kernc notifications@github.com 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 https://github.com/kernc/backtesting.py/issues/141#issuecomment-691358103, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBVCQF5TVVITVN4FSKJXOTSFK2EDANCNFSM4RINCTPA .
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).
OK thx! That is an interesting idea to use the OHLC
On Sat, Sep 12, 2020 at 1:26 PM kernc notifications@github.com 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 https://github.com/kernc/backtesting.py/issues/141#issuecomment-691534855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBVCQGWWZO3MRGBGTNTPG3SFPDORANCNFSM4RINCTPA .
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: