Comments (10)
There are multiple use cases I can identify in your question.
- 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.
- 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.
from vectorbt.
In the meantime you can do something like this:
price = np.where(entries, open_price, close_price)
from vectorbt.
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).
from vectorbt.
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.
from vectorbt.
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.
from vectorbt.
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.
from vectorbt.
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.
from vectorbt.
from vectorbt.
Correct. Will test it and release within a few days.
from vectorbt.
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.
from vectorbt.
Related Issues (20)
- Issues with combining multiple plots into subplots in 1 figure HOT 1
- Plotting Error: Subplot 'trade_pnl' raised an exception HOT 1
- Getting Daily PNL Portfolio Change
- What is the difference in the documentation of vectorbt PRO vs the open source vectorbt?
- What is the benchmark plotted in pf.plot().show()?
- How to use run_combs in combination with other signals?
- Questions about backtesting
- StopLoss group_by
- Plots missing "close" curve
- Import Errors HOT 5
- Plotting with custom benchmark_rets got error (VectorBT used undefined attribute 'obj')
- Datetime support with from_order_func HOT 1
- Dockerfile changes to run /apps/candlestick-patterns app
- Multiprocessing Error When Creating Portofiolio
- Pandas MultiIndex on axis 0 HOT 1
- Closing all positions at the end of the day
- MetaTrader5 Integration for Data and Backtesting
- DeprecationError: `np.float_` is deprecated HOT 1
- Extreme return values (billions %) in alternating long/short position backtests
- tuple out of range error on IndicatorBase.run HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vectorbt.