Sorry, I don't know how I can help. Let me quote from above
@CooleRnax said in Issue with positions when live trading:
I use custom broker for bitfinex
That's the key. Your custom broker has to let the engine know there are open trades. Because trades start with an opening order, you need to create fake orders that will trigger the start of a trade if you want to restart with an open position.
@Rumen-Nenov said in Multiple Timeframes with Multiple Datafeeds:
For multiple datafeeds however, looks like backtrader includes both the 5 min and daily timeframes in same set of feeds (self.datas)
For a single data feed too. Each and every data feed is present in the self.datas iterable, exactly in the order in which they were introduced in the system.
@Rumen-Nenov said in Multiple Timeframes with Multiple Datafeeds:
and from here on I cannot pass the data I want to the relevant indicators
And why not? They are data feeds, they can be passed to any indicator.
@Rumen-Nenov said in Multiple Timeframes with Multiple Datafeeds:
Not only this but the daily data also messes around with my intraday indicators.
Exactly how? This would be the first time.
@Rumen-Nenov said in Multiple Timeframes with Multiple Datafeeds:
for i, d1 in enumerate(self.data1):
Sorry but self.data1 is a data feed and not and array of data feeds. This is for sure not in the documentation. It seems you assume that daily data feeds get magically all packed inside self.data1. No.
See here for what self.data1 means: Docs - Platform Concepts
What you need is to have a convention for the addition order of the data feeds to cerebro. If you add a 5-min / 1-day data feeds per instrument, you can use something like for i in range(0, len(self.datas), 2), where self.datas[i]will have the5-minfeed andself.datas[i + 1]will have the1-day` feed.
There is code to check the position in the post you linked.
There is no such thing as old or new.
The chart you show below is what you get when executing on the console (which in most cases will use tkAgg)
The chart above is what you get in Jupyter. I personally don't use it but iplot=False worked when it was developed. I will have a look (in any case you are still constrained by the Jupyter configuration for the aspect)
The plotting code doesn't do recursion and doesn't see see the embedded indicators. The solutions you attempted as shown in the documentation page you linked are for the indicators and operations which happen directly in the strategy code.
The only trick I can offer you (not tested)
Create your indicator.
Create moving averages of period 1 which use your embedded indicators as data
Something as
my_indicator = MyIndicator(....)
emb_ind_1 = bt.ind.SMA(my_indicator.embedded_indicator1, period=1)
Now, the SMA doesn't know still where to plot itself, because the indicators won't be plotted.
Try then:
emb_ind_1.plotinfo.plotmaster = self.data
emb_ind_1.plotinfo.subplot = True
which says that they should be considered indicators of self.data for plotting purposes and be plotted in an own sub-graph.
@Mango-Loco said in Adding MA to Equity Curve:
def __init__(self): self.l.ma = bt.indicators.MovingAverageSimple(self.l.value, period=20) def next(self): self.l.value[0] = self._owner.broker.getvalue()
There is a problem there. The moving average is calculated before you set the value. Which means that the moving average is constantly calculating the average of Nan values.
You need to define an indicator which stores the value of the broker. You instantiate it just before the moving average and then do the moving average of that.
The subclass from @vladisld does for sure work.
You may also read the file with pandas.read_csv, skip what you need and pass it to Cerebro as a PandasData feed.
@Jenel-Videos said in StringIO Object to DataFeed:
data = btfeed.GenericCSVData(
dataname=d["FETBTC"].getvalue(),
After creating file (a pseudo-file) actually, why do you pass a string instead of the file-like object which you have already created?
The documentation says it:
Specific parameters (or specific meaning):
- ``dataname``: The filename to parse or a file-like object
Your best approach:
Load it with pandas.read_csv
Separate by symbol by using, for example, the clause where (that is, you create a mask that considers only the name of a ticker)
Write the result of each mask to a separate csv file.
The last step can actually be forfeited, because you end up with several pandas.DataFrames which can be directly fed to cerebro via PandasData
Don't take me for rude, but you say "trailing stop fired ...." and I could also say "trailing stop not fired ...".
There is no indication as to what you are doing, what's happening, if that is actually the right behavior.
Even if what you say would make some sense ... the following is completely wrong:
@fede3u said in Trailing stop fired by High and Low instead of Close price:
How can I modify the logic of the bt.Order.StopTrail.
You can also go and try to modify how the markets work. It may be easier and it will probably fit what you have backtested with something you have modified to fit your wishes and not to try to model how things work in the reality.
If StopTrail doesn't do what you expect, these are the possible reasons:
You don't know how such an order works in real markets
You do, but it's not the order type which fits what you try to model, but you have still chosen to do it.
Imho: very wrong way to approach your backtesting.
@chrismo said in Continuous working of limit orders:
The first NOTIFY ORDER shows the calculated bollinger.lines.top from the previous discrete bar (the Limit order.price of 254.37602), which I assume is filled at 254.37602 now that the current close is 260.0. We have a short trade.
See, "assuming" when you are trading is a dangerous business. Instead of relying on what you passed, why don't check the actual execution price? order.executed.price. It's in the documents. There is an entire section with several entries about order.
For excample Docs - Order Creation/Execution
@chrismo said in Continuous working of limit orders:
which is using the Close prices, not the Limit order.price.
That's again your assumption. Check the right things and you will see that the calculations are right.
@chrismo said in Continuous working of limit orders:
How do I get the code to use the order.price
You CANNOT. You can say that you don't want an execution which is worst than the Limit price, but it can be different if the price gaps in your favor.
With OOP the obvious approach is having a base class which defines the entry setup (invoked for example with method name check_and_enter.
That same class defines the logic to call another method for the strategy, for example: check_and_exit.
Subclasses of the base class have all the same entry method, but override and have different logics for the check_and_exit method.
@oakenstream said in Optimization with multiple feeds:
I dont exactly see where it is
Neither does the rest of us.
@oakenstream said in Optimization with multiple feeds:
Hey, is it possible to optimize with multiple feeds?
Yes, we can.
Disable the observers with stdstats=False
Let me try to summarize your findings:
Something to be expected, I guess.
25% (total or of the 80%, it doesn't matter) is spent in collecting statistics for visualization (i.e.: "observers")
And your answer is:
@tianjixuetu said in which line code(function) consume more time when doing a backtest?:
,when I prohibit the self._next_observers()
Once again, have you tried to read the documentation? Because you can disable the standard observers when invoking cerebro (look for stdstats in the cerebro documentation. It is also used in several samples and blog posts.)
And
And you answer is
@tianjixuetu said in which line code(function) consume more time when doing a backtest?:
and reduce the analyzer,
backtrader doesn't plug ANY analyzer as a default for some good reason. It would seem you actually don't need many of the analyzers you are plugging in.
And the conclusion is?
Your custom broker should retrieve any open position and notify that (like if the position had been just opened) to let the trade accounting know when a position is actually being opened.
Simple logic. That mechanism will also include any position which you may have chosen to manually open, so take it into account.
order.executed contains the data on which the action took place.
Try data._name if you have named it when adding it to cerebro vía adddata(xxx, name='yyyy')
If the dataname parameter in your data feed is something meaningful like a ticker name, try: data.p.dataname (the dataname parameter can be anything, for example a handle to a database)
@tianjixuetu said in Maximum number of data lines?:
because according to the author and cocument,the indicator caculate using vector, can be not using event driven.
This is what you said, that indicators cannot be calculated in event-driven mode.
@tianjixuetu said in Maximum number of data lines?:
The calculation for indicators is vectorized if possible (source data can be preloaded)
Everything can be run in event-only mode with no data preloaded, just like if things were live.
And the documentation clearly says that the default mode is "vectorized" if possible. If not, the indicators will be run in even-driven mode (as if things were live)
@chrismo said in Continuous working of limit orders:
For the next 30 minutes (i.e. until the next price update), I wish to work a limit buy order at a price of 10.
When you issue a Limit order and unless the price is a match, it is active until the valid.
In any case there seems to be some misunderstanding, because there are no "next 30 minutes", because we work with discrete bars, 30-minutes in your case. So the order is evaluated from bar to bar.
@chrismo said in Continuous working of limit orders:
Once we have the next() update, if the close is now 9 (or lower), I can be 100% sure that I have a fill at a price of 10
If that's the case, you will already have been notified of order execution. There is no need to be sure of anything. The fill price can be better than 10 if the opening price formed a gap in your favor.
@chrismo said in Continuous working of limit orders:
And for any close of >= 10, I will assume I have no fill.
There is nothing to assume. There will have been no notification.
@chrismo said in Continuous working of limit orders:
so for each half hour, the self.bband.lines.top and self.bband.lines.bot levels are updated to work limit orders for the subsequent 30 minutes.
The indicators are continuously updated, but the orders are inmutable. You will have to cancel the existing order and issue a new one to match your current requirements.
@chrismo said in Continuous working of limit orders:
Is that possible to implement?
Of course, as pointed out above. Cancel and reissue.