Portfolio mode providing price of an order about vectorbt

[polakowo]

There are multiple use cases I can identify in your question.

1. Your data is indexed, say, by days and you want to buy at open price and sell at close price within a single day.

It won't work. Only one action is allowed per time step, that is either you buy, sell, or do nothing. The reason for this is obvious: we are working with vectors, your time units are atomic and you cannot represent multiple actions as a single number. If positions can start and end within a single time step, you won't be able to track them. This is day trading anyway and requires smaller units of time. For this, you will need to re-index your price into multiple time steps, say hours.

2. Your data is indexed, say, by days and you want to buy at open price one day and sell at close price the other.

This also isn't supported yet, but can be implemented. What can be done on my side is the following:

I can adapt the order_func_nb from here to also return the custom price along with the amount of shares to order. So, for example, you could create your own order_func_nb which accepts a range of positional arguments such as open price, close price, and so on, and at each time step returns the chosen price value along with the amount to order. This way, you can specify your own price at each time step.

If this makes sense to you, I will release it with the next version of vectorbt in the following days. I will also post an example how to use it for your particular use case.

[polakowo]

In the meantime you can do something like this:

price = np.where(entries, open_price, close_price)

[yamen]

Yep, I think modifying order_func_nb makes most sense. It won't always be open or close, it will sometimes be a price within the range of a bar. There will be no entries / exits on same bar, and my bars are time-indexed (which I assume will 'just work' as there's no day only assumptions in code?).

This does however make the concept of the price series argument in portfolio slightly odd, beyond the use in buy and hold comparison, as all you're really working off is the entry / exits in the positions. I suppose price is still used for (say) MAE, MFE and other calcs that you may want to perform on positions.

(FWIW I'm not entirely sure how I can take positional arguments in any called order_func_nb, I know Python but am a Numby amateur).

[polakowo]

There are no day assumptions in code, it will work on minute scale in the same fashion as on hour scale, the only difference will be in the annualization factor which is determined from the index automatically anyway. The only assumption here is that your time steps are uniform, since Numba and Numpy don't see your index and they assume that the gap between rows in your matrix is always the same and constant.

Right, price is required for building the equity curve and metric calculation. Price in this context isn't just open or close price, but order price. Since there can be only one action per unit of time, there also can be only one price per unit of time, thus one price series should be sufficient for any use case. The current implementation assumes that you know your order price beforehand.

Now, if you get the ability to define your custom order price on the fly, the Portfolio class will still have to build a price series out of the values you defined. If you provide only the price at each entry and exit signal, you will get many nans in between which will cause havoc in performance modeling. I'd definitely need to do more tests here.

[yamen]

Hmm actually it's more complicated than that. I'm using the library in the sense that you describe it - for exploration and data mining, instead of strictly 'backtesting'. I think that's what makes the most sense for what you've built.

So, each 'column' in my world is a different strategy. While they operate on the same time index, different strategies could have different entry / exit prices (as well as, as you already do, directions and number of shares). When you start considering potential multi-asset positions, it starts to further devalue the idea of a 'portfolio price'.

From what I can see, the main criteria is having consistent time indexes, and consistent gaps between them.

The assumption that time gaps are the same does not hold btw, there's often a gap in market close or overnight. I can fill these with NaNs, but what are they used for?

Perhaps my intraday use cases are stretching the intent of the library.

[polakowo]

Apart from multi-asset positions which need some rethinking in terms of vectorization, I think the current implementation might still work for your use case.

For each column and strategy you have in your entry and exit signal dataframes, you can define a column in your price dataframe. If you've got signals of shape (365,1000), you can define your price to be also of shape (365,1000) such that each strategy corresponds to a different price series. There are no big limitations of what you can effectively achieve here. You can even define some weird intra-column dependencies, as in order_func_nb you have direct access to other columns.

Maybe I missed the point completely because I mainly trade with crypto and have no expertise of trading in stock markets, where rules might be much more complex than that.

The assumption regarding gaps isn't a strong one, you might be still ok having gaps as long as you account for them in metrics that use annualization or measure duration of something.

[polakowo]

What about the following idea:

We can use price as market price (open, close, or any user-defined series that reflects asset's price at each point of time). This price will be used solely for tracking the portfolio value.

Furthermore, you will be able to specify your custom entry/exit price in order_func_nb. This price will be used in order execution and to derive P/L of positions, etc. Those values will be then stored for you in a separate dataframe (let's say order_price) in Portfolio instance. It will contain non-NA values only at points where an order took place, otherwise NaN. It appears to me as the most suitable solution.

[yamen]

Sounds good to me, probably won't understand challenges of approach until we actually get into it. As long as each strategy can provide its prices for entries / exits and that performance of each individual position uses these (noting open positions will use the 'main' price), then I think this will work. Interpretation would be that the 'main' series represents the `open` or `close`, and that the order series represents a price traded within that timeframe, but potentially not the `close`.

…

On Tue, 19 May 2020 at 10:00, Oleg Polakow ***@***.***> wrote: What about the following idea: We can use price as market price (open, close, or any user-defined series that reflects asset's price at each point of time). This price will be used solely for tracking the portfolio value. Furthermore, you will be able to specify your custom entry/exit price in order_func_nb. This price will be used in order execution and to derive P/L of positions, etc. Those values will be then stored for you in a separate dataframe (let's say order_price) in Portfolio instance. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVTZYJCRTDFPP7MMH6KKDRSHD2LANCNFSM4NDYJFDA> .

[polakowo]

Correct. Will test it and release within a few days.

[polakowo]

The 0.9 release is finally there, took me a bit longer because of annoying Numba bug.

I completely reworked portfolio and switched the internal representation of orders, trades and positions from matrices to records (still vectorized), which takes less space and is more and easier extensible. Because of this, portfolio modeling is now 2x faster.

I also added the features entry_price and exit_price as requested, you can find the whole signature in the docs. Accumulation of signals is now disabled by default, which means that given two entry signals in a row will only execute the first one. You can enable accumulation via accumulate keyword argument, which will allow multiply entries/exits. If there is entry and exit signal at the same time, it will buy/sell the difference in size.