@bigchappa said in Does broker.orders contains all the old orders?:
When you say track the position performance information externally, do you mean record the performance in notifies and store it in a file then load it up the next session?
Right. Just collect whatever information you need to re-create the orders you'll need for the next session - that's all.
@bigchappa You may definitely track the position performance information (p&l, size/price per lot if relevant, etc ... ) externally to the session and load it prior to the next session start.
It is probably a good idea to keep no pending orders between sessions and/or overnight - especially with IB, with its nightly server shutdowns/maintenance.
As a precautionary measure, all pending orders could be cancelled on session end ( or session crash/abort ) and/or prior to the next session start, and re-submitted upon next session start. ( Although there is some slim theoretical chance for the race here , practically it very rarely happens if at all, especially if you start your session at the start of pre-market hours and stop at the end of post-market hours.
@terryduan said in Help on YahooFinanceData:
bt.feeds.YahooFinanceData(dataname = 'MSFT', fromdata=datetime.datetime(2019,1,1)
Most probably because of a typo:
bt.feeds.YahooFinanceData(dataname = 'MSFT', fromdata=datetime.datetime(2019,1,1)...
should be:
bt.feeds.YahooFinanceData(dataname = 'MSFT', fromdate=datetime.datetime(2019,1,1)...
@bigchappa Storing and/or synchronizing pending orders in live trading is a controversial topic and requires taking care of many corner cases. It was discusses numerous times on this forum. Example:
https://community.backtrader.com/topic/1419/serialization-of-bracket-orders/2
As for actual implementation related aspect, the source code for IB related implementation is shared between /backtrader/stores/ibstore.py and /backtrader/brokers/ibbroker.py files.
AFAIU the IB broker implementation doesn't even request the list of open orders from the server upon initialization (it just requests the current positions) - so if you need this functionality - you'll probably have to extend the current implementation.
@jacksonx Please see the comments in the code. Backtrader broker requires position's datetime attribute to be set. The value is not that important and could be any valid python datetime object. In my case this date is taken from the previously stored transaction.
@ringtail Basically it is possible to iterate all the indicators and calculate the maximal minperiod. However it is probably not very feasible since the indicators are usually initialized/created inside the strategy, where the data feeds parameters should be specified way earlier - before the strategy creation. Not sure if there is an easy way to trick the data feed parameters during the strategy initialization - never done that before.
@kk said in Zero records while loading Data from CSV:
data = bt.feeds.GenericCSVData(...
Few points:
AFAIU, creating the datafeed, being it GenericCSVData or PandasData will not load the actual data ( it may differ for other data feeds) . Data is loaded during the Cerebro engine run. It could be loaded all in once using 'preload' if Cerebro preload parameter was set to 'True' (default) or on the go.
len(datafeed) returns the length of the iterated part of the datafeed - even if the datafeed's data was fully pre-loaded. So even after datafeed.preload() method is called - len(datafeed) will still return zero ( since it hasn't been iterated yet )
one may use datafeed.buflen() to get the actual number of loaded bars. Once again buflen method will return zero upon data feed creation - since data was not attempted to be loaded at this point - at least for CSV and Pandas data feeds.
Please correct me if you know/experience otherwise
@kk Please do not post the code as image. Mind the top of the page:
"For code/output blocks: Use ``` (aka backtick or grave accent) in a single line before and after the block. See: http://commonmark.org/help/"
For better support it usually required to copy/past part/all of your code to test locally, which is not feasible to do with images.
@ringtail why not just load the data feed earlier (to match the MA(10) period ). Since the backtesting will start only when the indicator is ready - you'll get the behavior you wanted.
@kjiessar said in Memory Leak with multiple cerebros:
with Pool(multiprocessing.cpu_count, maxtasksperchild=1) as pool:
Long ago I had the same issue when optstrategy was used with multiple strategies ( in which case Cerebro will use the multiprocessing Pool.imap for optimization.
Ended up changing the Pool.imap parameters to use chunksize=. See more here:
@kjiessar how the memory consumption changes without plotting?
@csibi-levente14 AFAIU close method will just issue a sell/buy order to nullify (close) whatever position you have - so in case of long position the sell order will be issued, vice versa for short one.
BTW, the issued order is returned by the 'close' method - so you may examine what order was issued.
regarding the notify_order:
AFAIU the notify_order notification for given order object is only sent to the order's "owner", where the "owner" being the strategy instance which created this particular order in the first place.
So it seems that when multiple strategies are running, only the strategy that originated given order will get the notify_order notifications for this order instance.
As for notify_data notification - once again AFAIU - it works differently, since data objects are stored per Cerebro instance and not per strategy - so notify_data notification will be called for each data object on each strategy.
It seems the notify_store works the same as notify_data in this regard.
@tradersnorth said in Forex custom commission and multiplier:
cerebro.broker.setcommission(leverage=50, stocklike=False, commission=comm, mult=100)
AFAIU setcommision method just creates a generic CommInfoBase object using passed parameters to this method.
It means the commission parameter is expected to be (quoting from CommInfoBase docs):
``commission`` (def: ``0.0``): base commission value in percentage or monetary units
In your case, using cerebro.addcommissioninfo method is probably more appropriate. It allows passing a custom CommInfoBase inherited commission object.
@brunof I believe the docstring of the Strategy.buy() is the correct one.
Looking for example at the mapping of the order execution types to the IB broker order type we may see that Order.Close execution type is mapped to the MOC order type.
Quoting the IB docs for the MOC order type we may see:
"""
A Market-on-Close (MOC) order is a market order that is submitted to execute as close to the closing price as possible.
"""
So you are right - the docs should be updated.
@sangoman said in Buy / Sell executing - but not being identified as Trades:
Backtrader does not seem to be identifying the Buys and Sells as Trades
AFAIU Backtrader reports a trade when particular position goes to zero. So if trades are not reported it could be related to the maxRiskSizer that you are using.
Could you attach the log output of your run and print the order sizes and the position on each order notification?
@bigchappa said in How live data with stock reverse/split is handled?:
how the framework is going to handle stock split with live data
Could you please elaborate about your expectation of such handling ?
AFAIU, Backtrader doesn't provide any notification about expected ( or just occurred ) corporate action, be it split or dividend or any other event.
There is however support for 'adjusted close' prices for some history data feeds ( YahooFinanceCSVData for example) if such prices are provided.
@adrianyuen Backtrader API only defined a minimal set of order execution types that are compatible will all the supported brokers (Market,Limit,Close,Stop,StopLimit,StopTrail,StopTrailLimit).
However, the buy/sell methods of the strategy accept kwargs parameters that may add additional, broker specific, information to the broker or overwrite the default values of the order parameters.
Quoting the docs for the IBOrder:
Any extra parameters supplied with kwargs are applied directly to the
ib.ext.Order.Order object, which could be used as follows::
Example: if the 4 order execution types directly supported by
``backtrader`` are not enough, in the case of for example
*Interactive Brokers* the following could be passed as *kwargs*::
orderType='LIT', lmtPrice=10.0, auxPrice=9.8
This would override the settings created by ``backtrader`` and
generate a ``LIMIT IF TOUCHED`` order with a *touched* price of 9.8
and a *limit* price of 10.0.
This would be done almost always from the ``Buy`` and ``Sell`` methods of
the ``Strategy`` subclass being used in ``Cerebro``
@giebels try to specify the correct timeframe and compression for you data feed. If not specified, it defaults to daily prices, and it seems your data are in minutes time format.