How to make Market order valid.

Li Mike

Dear backtrader, as the doc says, valid parameter has no effect for Market order. But In some scenarios, I want it to take effect. Suppose one day I issue a market order, the next day it stop trading until one month later, it restore trading. In this scenario, I want the order to be valid for 10 days, how to do it？

Li Mike

I mean how to make Market order expires.

ab_trader

Market order is executed or rejected as soon as it gets to the market. This is by definition of the market order..

@Li-Mike said in How to make Market order valid.:

Suppose one day I issue a market order

And it is executed with the first available price or rejected.

Li Mike

thank you for your reply. I know it will be executed on the next bar, one month later in this case. That's a long time and I do not want my order be alive for so long. So If I can set it to expire after 10 days, then the order will not be executed one month later, this is what I want.

ab_trader

If you don't want to trade for one month, than issue market order with one month delay.

Li Mike

@ab_trader When I issue an order in the next method for a stock on the current bar, I don't know the stock will stop trading next day until next month.

ab_trader

If you have no prices, than (I assume, not tested) bt will reject the order on this day. If not and order will be hanging in the system, you can cancel it by yourself.

Li Mike

@ab_trader thank you for your reply.
Suppose the data is as follows：
2019-01-01, ...
2019-02-15, ...
At first bar, that is 2019-1-1, I issue an order, then it will be executed at the second bar, that is 2019-2-15. Now, I want the order to expire on 2019-1-10. How to do it?
I think if I can set a valid day for the market order, the problem can be solved easily.

run-out

Your order object has the datetime stored that it was created. You can compare this to the current datetime in next() and cancel the order if too much time has passed.

The datetime is in float format. If you stored order as self.o:

self.o.created.dt would yield... 737676.5138888889

Use bt.num2date to convert the float to datetime.

run-out

As a side note, I like to add the start bar length to the order object when I create orders. This makes determining how many bars have passed slightly easier. I create a new field, I call it obar for originating bar, but you can call it whatever.

self.o.obar = len(self)

Then all you need to do is compare the current bar length to the one stored in the order object.

if len(self) - self.o.obar > n: 
    self.cancel(self.o)

vladisld

@run-out I would suggest to discuss this as a separate topic or even as an enhancement issue in the repository.

One note about it is to check that it will work well with all exactbar cerebro parameter values.

run-out

@vladisld Did you feel there would be an issue with this? How do you feel this would be impacted using exactbar? Thx

vladisld

AFAIU exactbar parameter controls the amount of memory dedicated for 'lines' object storage. Quoting:

"
True or 1: all “lines” objects reduce memory usage to the automatically calculated minimum period.
If a Simple Moving Average has a period of 30, the underlying data will have always a running buffer of 30 bars to allow the calculation of the Simple Moving Average
"

So if some old bar is stored in the order, and somehow referenced in the future - will it still be in memory at the time of reference? IMHO worth to take a look.

run-out

OK, will do when I get a moment.

run-out

@vladisld said in How to make Market order valid.:

So if some old bar is stored in the order, and somehow referenced in the future - will it still be in memory at the time of reference? IMHO worth to take a look.

I created a script to check this. I ran a simple moving average from the beginning of the year with period=22 so that the min period would start at the beginning of February. I then made an order with no exit.

Next I added the bar length to the order using self.o.obar = len(self)

Next I ran the script to the end of the year and printed out the self.o.obar and the actual length using len(self).

Then I ran the script using all of the possible variables for exactbars:

With the default False value each and every value stored in a line is kept in memory

Possible values:

    True or 1: all “lines” objects reduce memory usage to the automatically calculated minimum period.

    If a Simple Moving Average has a period of 30, the underlying data will have always a running buffer of 30 bars to allow the calculation of the Simple Moving Average

        This setting will deactivate preload and runonce

        Using this setting also deactivates plotting

    -1: datas and indicators/operations at strategy level will keep all data in memory.

    For example: a RSI internally uses the indicator UpDay to make calculations. This subindicator will not keep all data in memory

        This allows to keep plotting and preloading active.

        runonce will be deactivated

    -2: datas and indicators kept as attributes of the strategy will keep all data in memory.

For all input parameters for exactbars the results were the same. The bar length references held steady for the order and the length of the bars run. This would seem to indicate you could use the self.o.obar method to keep track of the starting bar of the order and make use later on in the order's life.

As a side note, I have made extensive use of adding information to orders as attributres when I will need to evaluate that information bar by bar over the order's life. This has been very convenient.