The documentation/blog has several examples with multiple instruments, be it with resampling of the same data or with different datas. Some examples:

https://www.backtrader.com/docu/data-multitimeframe/data-multitimeframe.html

https://www.backtrader.com/blog/posts/2015-09-03-multidata-strategy/multidata-strategy.html?highlight=correlated

https://www.backtrader.com/blog/posts/2016-08-15-stock-screening/stock-screening.html?highlight=tsla

You simply have to tell the platform form which instrument to buy/sell.

There isn't enough information to even attempt anything. For example: the only provided output is from the modified source, without having the actual command line execution

As such one can only try to point the low hanging fruits. One would be:

Are you pointing to the right port? (usually 7496 for production and 7497 for paper trading)

The default port used by the sample and the IB ecosystem is 7496.

You quote above the following command:

./ibtest.py --data0 EUR.USD-CASH-IDEALPRO --resample --timeframe Minutes --compression 1

and this is theoretically working with the demo. But the demo also runs (default, can be of course be changed) on port 7497.

Cash Products like EUR.USD-CASH-IDEALPRO are allowed (afaik) to all IB customers (as long as your account is funded I think). Whether demo, paper trading or real account, that product is available for everyone. And the code (which relies on IBPy for interfacing to TWS) doesn't know what it is connecting to. The account type is controlled by the TWS (or IbGateway) instance you connect to.

Thanks a lot for this detailed and helpful explanation!

Choosing GPLv3 is a fully conscious decision. What other libraries may or may not do is not of much interest. Each author or organization willing to release open source code weights the pros and cons of different approaches and in this case the GPLv3 was chosen.

Having a license doesn't preclude being able to have a 2nd license for the platform. In most cases this pattern is filled with a direct negotiation between the parties (one interested in an acquisition with a different license, the other willing to re-license) Whether such a pattern fits your case is something which cannot be simply assumed.

Deleted by author.

Not at the moment. It's a matter of time. It would have been the chosen API, had Oanda had v20 ready.

Slack is more suited for teamwork in the sense that things are worked out together and Slack, for example, takes on the role of E-Mail. A community seems better suited for the current state of things.

It's amongs the things to be considered.

A full exception trace would be a lot more useful than the selected final line, which only says that something hasn't got a length.

The full trace will give hints as to where the error was triggered and not where the error finally happened.

@backtrader if you don't mind I would correct your summary slightly:

@ab_trader is looking to use the signals and position sizes provided by bt, and mirror them to broker account by hands. bt will keep position sizes, cash, value and commissions.

In that scenario there is no need to load the positions, cause they are mirrored by trader and are the same in bt and at broker account. In case of the discrepancies bt strategy can be easily adjusted.

The broker is being used for signal and position sizes providing as well as for tracking of the cash and value (no need to support the real broker).

I believe this summary reflects my proposals better. :)

There isn't at the moment

checksubmit controls if a submitted order can be accepted by the broker by simulating execution and with it checking if the current cash reserves are enough. It actually pseudo-executes all pending orders, because an order could actually be 1st opening a short and increasing the pseudo-cash reserves.

But this is only pseudo-execution. When the actual execution takes place, the actual cash level is checked again and execution will be rejected if not possible.

Note: with CFD products you should consider taking the interest into account for both long and short positions.

Note2: that's the problem with snippet typing (as opposed to testing it), they usually contain typos. And the same applied partially to the documentation. Both posts have been corrected to avoid future confusion and the docs updated.

Should be (meaning it will be there as soon as possible, because it should be there in __init__ and not after it)

The idea is always to have a generic model, like it is the case with the timezones, in which you may pass pytz instances or something that, more or less, complies to the interface of pytz.

A similar approach will be taken.

figured that out. the stop price was actually triggered. The high for the bar is higher than the stop price. As always, the explanation is simple, but it takes time to find it out :)

@ab_trader true. anyway it's not what I'm looking for as commission is not included into calculation.

@backtrader Why wouldn't you close the position with close?

already did that. I used order_target as my zipline code that I'm porting to backtrader used order_target* APIs.

Hello,

I have the following scenario in mind:

Pass the system the following inputs:

historical data in period duration (5Y) out period duration (1Y) parameters and ranges

Let's say we have 10 years worth of data, then the ideal processing would be as follows:

Break the data in multiple chunks according to the periods defined above In Period 1: 2000-2005 Out Period 1: 2005-2006 In Period 2: 2001:2006 Out Period 2: 2006-2007 In Period 3: 2002-2007 Out Period 3: 2007-2008

Than start executiing the execution.

Optimize parameters for first In Period (2000-2005) - cerebro.optstrategy() Get best parameters from previous run and test on Out Period 1 - cerebro.addstrategy() Optimize again on the next In Period Test with the parameters from previous step on the next out period Optimize again ...... Test again on the next Out Period .....

At the end plot the combined strategy during all out periods from 2005 to 2010 by taking into consideration that parameters are being changed every year with the optimized values from last 5 years worth of data.

I am open for any ideas for implementation.

So far I am thinking to read the data in pandas, break it and loop through it in chunks and feed it to cerebro consecuently.

I have no idea how to combine the outputs from each cerebro run and how to plot all individual strategy executions into a single figure.

BR,
dpetrov