Even if you downgraded to
0.5.1 it would seem some of the packages that are needed as dependencies are more modern than the ones available when
0.5.1 was released, hence the errors.
It's simply a conundrum.
You cannot put things into the future. But you can bring things from the past into the present.
See the implementation of the
Ichimoku Cloud which also needs to put things into the future.
- import these orders and test against OHLC data that I have in CSV files
Yes for sure. See: Blog - Evaluating external historical performance
- use backtrader to optimise with different stop and limit values
You have to switch from historical order evaluation to reading the orders, implementing them as either a data feed or an indicator and use the data points to trigger your orders. This is something that some users have apparently done in the past.
The data feeds are extensible with new lines, but you may choose to use the existing OHLC fields to code information. This can be as easy as to put this into a
GenericCSVData. See Docs - Datafeeds Reference
In the case of indicators, you would define the lines and then read values from the defined lines
- if possible test with trailing stops
Yes. And Trailing stops with limits and with the trailing amount being an absolute value or a percentage value
- if possible implement a mechanism that has a "trailing start" - where I monitor the status of the last closing bar and decide whether or not execute the order in this CSV file.
Unsure about what you mean. You can always monitor the status of the last closing bar and decide whether to issue the order which is signaled via the data feed or indicator, as pointed out above.
That 21.28 is not easy to spot if not looking for it ... now the situation is clear.
TimeReturn produces a per year result, because a return needs only 2 values, the starting and ending values and it doesn't matter if there is no variability, there is no division by zero.
The SharpeRatio needs at least 2 return values and they have to be different. That's why it is usually done on a multiyear basis.
To get a yearly Sharpe Ratio you have to work with timeframes below
Is there a simple way I can code this using the existing SharpeRatio analyzer?
Wait for "IB and Trader Workstation connectivity lost"`?
In any case notice that the definition of the
WilliamsR indicator was actually not original and is just the inverse of the fast line of the indicator (
See one reference which describes it: https://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:williams_r
Which implies that (as mentioned in the article) you can use the
%k of the Fast Stochastic instead of the
I saw on other posts that for RSI for example there is a param safediv, but its not the case with Williams R.
Because some people found the problem before with an indicator known to work better than
The real problem being the application of those indicators to scenarios where the variability of the prices is
NULL for the considered period, i.e.: the trading is so thin that there is actuallly no trading and no price change. And the lack of variability creates a division by zero.
And the designers/creators of the indicators were working in markets where things happen. Try to answer what has to happen when there is no variability during the entire considered period
What would be the solution for this?
At some point in time the indicator will be patched to avoid raising the exception. But this is not the solution to the actual problem, which is the application of an non-appropriate indicator to a data set.
Should I use another indicator?
That's for you to decide, obviously.
Not really. The reproduction attempts failed.