@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:

• Over 80% of the time is spent in actual backtesting (as opposed to something like data loading, which is productive but not real backtesting)

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

• 25% (total or of the 80%, it doesn't matter) is spent in collecting statistics for analysis (i.e. "analyzers")

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)

It works for me.

@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.