@jacob said in Indicator using multi datafeed: operate only on overlapping bar:
this is a great workaround for this issue/bug.
This is not a workaround. It is clearly stated in the FAQ: Community - FAQ
The system cannot know which timeframe/compression your data feed has unless you tell the system.
@cept0r said in Issuing multiple orders, how do I only issue one order at a time?:
So I'm wondering what I'm doing wrong?
Evidently your script can work only for pos == 0 case. As soon as position open (and we can see this in the logs) i.e. pos != 0, your second condition if pos > 0 and not self.long: doesn't work anymore.
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.
My example was with daily bars, as I think is more close to the reality. At the end, forgetting about the -coc option for a moment, if you have a live order feed sending only daily bars, you could have that planned task at, for example, midday, that send the MOC order and gets executed with the close price of the daily bar.
There is difference between backtesting with daily bars and having a live feed which delivers daily bars. The latter probably constantly updates the current daily bar and that's why you think that already at noon time it may be possible to send a MOC order.
To achieve the same effect during backtesting you need one of this:
intraday data and replay daily bars
Set cheat-on-close and allow using the close price
Use filters and break the feed into OHL + C steps (see the Pinkfish Challenge - and the sample in the sources)
For the MOO I can send it to IB with kwargs as you´re proposing, but I cannot get the same effect with backtesting, basically because 1) Backtrader doesn´t support natively MOO orders (what about more order types support for the future? :slight_smile: ) or 2) as I don´t have "planning tasks capability" I should know which one is the last bar - 1 on the day, to send a Market Order, before it close, and simulate MOO behaviour...
Yes you can. If you use daily bars, whenever you get a bar during backtesting, you are at the end of the session. Send for both cases (backtesting and live) a Market order and the extra kwargs. The standard backtesting broker will ignore it and the IB broker will overwrite the order type.
if I do it with a background thread as proposed, I understand this is a real time capability, but no way to reproduce it on backtesting mode, isn´t?
Not at the moment
if implemented as points in lines (kind of time feed), wouldn´t be this more accurate to have same behaviour like in realtime with just 1 code?
At least it would have the same behavior right now for both scenarios.
Momentarily confused when trying out Kaber's code -- for those who care my code is python 2, and his code appears to be python 3. Changing super() to super(classname, self) successfully executes under python 2.
@vladisld Enjoyed the video. Believe the issue in the code was that it was iterating over rows and writing 1 row at a time to the database...
Can now write 13 years of 1 minute data in ~50 seconds. Needed to batch_size=10000 for it to work on a large data-set.
Problem solved. Now the real work begins.
@pomnl said in Race Condition Bug w/ Orders and Trades:
@run-out also, to put this into perspective, I currently run tens of millions of tests across these datasets. Just have to ask if you're able to do that with this strategy?
I was doing a factor analysis and the factor parr (eg first part precalculated) didn't change much. I have also used it in other cases where it slowed down. So not sure how it will work out for you. Good luck.
I think it's possible to have 1 large bar to form multiple bricks but not with the implementation in backtrader's filter, you have to implement your own renko filter. every extra bricks need to have a small time offset, due to the precision, the smallest value is 10 microseconds which is small enough to use I think.