Aside from just elminating duplicate holdings in a book, seems you could also use it to toggle in and out of different live portfolios based on specific conditions.
Let’s say I have two 10 stock live ports set up with automatic rebalance for bull markets (LivePortBull) and bear markets (LivePortBear). I also have a custom function market timer that returns a value on a scale of 1 to 10 whether we’re in Bull or Bear conditions.
Now I set up a new 10 stock Live “MktTimingPort” that toggles back and forth between the two Portfolio holdings with one buy rule
Allow sold holdings to be re-bought at current rebalance = Yes
I’ve set something similar up that utilizes an ETF Sector Rotation portfolio that moves in and out into a defensive ETF Portfolio based on a market timer function, since Hedging functionality isn’t allowed in ETF Ports. I’ve thought about also setting up individual “Best in Class” sector stock portfolios that toggle to reflect a sector rotation strategy.
While, I can’t sim all the parts comprehensively in my TimingPort, but I should be able to backtest how LivePortBull does in upcycles and how LivePortBear does in downcycles & backtest how well my custom function timer does differentiating the cycles and get a degree of confidence of how it will perfrom out fo sample, which is all I can really ask of a backtest anyway. You just wouldnt be to use this kind of model as a SA without the ability to simulate it all together comprehensively.
At least for me it could be MUCH, MUCH more useful if there were a RatingPos(“my ranking system”) function that worked the same as RankPos.
This is would allow me to backtest a book with two ports and this rule in one of the ports—at least for some types of port.
Example of why. Suppose I have a stock system that holds just the top 5 ranked stocks. And suppose I have maxed-out that port for liquidity. I cannot buy any more of those stocks without taking a large hit in slippage.
When I add a second port, I do not want that new port to buy any more of the stocks that show up in the first port. This is a good rule to use in that situation but how will that new port perform?
I could backtest this simply. Buy putting RankingPos(“First port ranking system”) > 5 as a buy rule in the second port.
Even if you have a rank tolerance or other sell rules that make the ports more complex, I would argue that for many this would be helpful in determining how the second port might perform. For example, you still could determine the usual minimum rank position or the average rank position that the first port selects for new stocks.
P123: If this is easy to implement, please do this. If it is not easy—cool—P123 is great without it.
BTW, SA developers would often be able to develop ports that—when combined in a book—do not ever buy the same stock. Quite a selling point, IMHO. And not that anyone would ever do this but one could even separate out a single good port into 2 ports generating increased revenue for 2 ports while improving the performance of the first port that selects the higher ranked stocks (attracting customers).
You can almost create almost the same functionality of a book using this inside a Portfolio. For example, set up a 20 stock “wrapper” portfolio that contains within four different 5 stock portfolios in the Buy Rule.
Portfolio(“5StockPort1”)=TRUE OR Portfolio(“5StockPort2”)=TRUE OR Portfolio(“5StockPort3”)=TRUE OR Portfolio(“5StockPort4”)=TRUE
Then set up nested EVAL rules that mixes and matches portfolios however you like based on specific conditions. Potentially very powerful. Off the top of my head, it would be interesting when I get more time to see if I could set up a “wrapper” 10 sector rotation Stock Portfolio that could contain buying long the 5 best ‘best in class’ bull sector stocks and shorting the 5 ‘worst in class’ bear sector stocks.
For that to work the First port would need to have RankPos<=5 as one of it buy rules. However, other First port buy rules could eliminate one (or more) of the top five ranked stocks, forcing the port to make fewer new buys (i.e. hold cash) in that rebalance period.
I think that’s right.
Fixing Portfolio() to be PIT is better.
Walter
EDIT: there’s also the issue of liquidity on the sell side.
It is not perfect. Some clarification and opinions.
RE: “For that to work the First port would need to have RankPos<=5 as one of its buy rules”
For a 5 stock portfolio with sell rule RankPos > 5 and no other buy or sell rules then the buy rule RankPos <=5 would be redundant. RatingPos > 5 in the second port would prevent you from buying stocks held in the first port.
But even if your ports are more complex, I would argue that many of the computer programmers, math whizzes and plain bright people at P123 might be able to use this to get an idea of the returns of the second port.
Re: “Fixing Portfolio() to be PIT is better.”
I defer to P123 but I think this would be very difficult to implement. And if they could, it would use a lot of computer time. Again I defer to P123.
RE: “EDIT: there’s also the issue of liquidity on the sell side.”
Yes. Great point! But the liquidity would actually be less for some books. In real life, you might not sell the sTock in the first port then buy it in the second. Instead, you would transfer it in the ports manually without any real buy or sell—or slippage. Actually, makes the slippage less than estimated and makes this more attractive for me.
It may be easy to implement. P123 already has historical lookup and buy exclusion list support for ports. Make these features dynamic and when the second port runs, it could lookup what the referenced port is holding for the week in question, build a temporary exclusion list and then run a regular sell/buy rebalance cycle.
Love it!!!. Would love to see it. And as far as my previous quote: if you trust anything I say about computer programing then I have a bridge I could sell you. I could do something in Fortran and DOS once. Does anyone remember these computer languages?
It’s exactly right. Portfolio() was added to prevent buying the same stocks with live systems. Most systems that are launched live should not have too much overlap (otherwise what’s the point), so it was meant as a safety check.
To make Portfolio() work in sims it would require a call to load the holdings, at every rebalance, from the transaction list (what it’s doing now is loading form the latest holdings). It’s not that bad as far as coding/testing/run-time-speed. Lets call it 3 days of a programmer.
There’s a new Feature Request for this. If it gets at least 5 votes we will do it.
I’m OK with two ports holding the same stocks, so Portfolio() exactly right. What I really want to avoid the crowding of a trade when two ports buy or sell the same stock(s) within a rebalance cycle.
What you say was accurate but it has been updated. So if you name a sim the sim you are running will look at the named sim and not buy what was held in that sim on that date.
E.g., buy rule in one of my sims where it works: portfolio(“nobuy”) = false
“nobuy” is the name of the sim whose holdings I do not want to purchase in the sim I am running.