I would like to propose creating an ordered-list member in each DataSet object for storing a "sell priority" for each symbol. This way when an account is out of buying power, one can quickly locate the weakest positions (external symbols) to sell in order to buy a new stronger position. Some comments:

1) It's up to the strategy code to set this sell priority for each symbol in the DataSet using some criteria (like recent performance).

2) There's no need for a two-pass simulation. The priorities set during the previous bar can be used to determine what the weakest position is for selling on the current bar because these priorities won't change that quickly between bars.

3) This enhancement is motivated by the difficulty of estimating a "buy priority" for the current priority structure Wealth-Lab now offers. Trying to _guess_ how profitable a stock buy will be in the future is next to impossible. Yes, I've tried setting the buy priority by -RSI (and several other factors), but these approaches failed to accurately predict whether the buy was a *future* winner. In contrast, it's easy to determine a sell priority based on past performance with good reliability--that's doable.

Honestly, I would replace the "buy priority" system Wealth-Lab now has for this new "sell priority" system, which I believe will perform much better. But both systems could be supported together as well.

1) Have you explored strategies in the Symbol Rotation folder? What you describe to me sounds like another rotation system that closes out a position falling from Top-N by performance etc. This is what these strategies do.

2) What is a two-pass simulation?

3) The Position.Priority is not a predictor of future performance. Its purpose is to prioritize positions when a low cash situation takes place. In fact, there's an option "Use Worst Trades..." that implements an extreme pessimism case.

QUOTE:
1) Have you explored strategies in the Symbol Rotation folder? ... sounds like another rotation system that closes out a position falling from Top-N by performance etc.

I've looked at them to some degree (earlier today), but not extensively. Their implementation is somewhat awkward with the current framework architecture.

In general, because your buying power is fixed, every Fidelity account is a rotational strategy when it comes to investing. All I'm saying is that WealthScript could have more intrinsic features to support this rotational behavior. Every investment portfolio is rotational because of buying power restrictions, so let's support this paradigm as much as possible.

QUOTE:

2) What is a two-pass simulation?

Sometimes all the state variables aren't stable or available on the first pass, so you tabulate what you have, then make another run. In this context, you are really using sell priority values based on the previous bar to determine what to sell on the current bar in a one-pass simulation. But if you updated your sell priorities on the current bar (first pass), then ran through the simulation again (second pass) to perform trading (buying and selling) for the current bar based on those updated priorities; you would have a two-pass solution.

I'm saying avoid the two-pass solution, and base your selling on "stale" sell priorities set during the previous bar. The results will be almost as good, and your simulation will complete faster.

QUOTE:

3) The Position.Priority is not a predictor of future performance. Its purpose is to prioritize positions when a low cash situation takes place....

When assigning the Position.Priority (buy priority), you want to assign the highest priority to those stocks with the highest win rate. And when you do, you get another 0.4% improvement in net income. [My simulations go from 7% (random assignment) to 7.4% (recent performance assignment) when I do.] In this context, to get that extra 0.4%, you have to predict the future. You're saying you don't care about that extra 0.4%.... Interesting.

My point is that by using selling priorities rather than buying priorities, you would make more money because the latter can't be determined reliably, but the former can.

---------------

I see every Wealth-Lab simulation as running a rotational strategy because investment income is finite. But I'm not sure if your vision of the framework's goals are the same as mine. I think you prefer to think in raw-profit mode for production investing, where I do not. We think differently.

Your "Sell Priority" is completely controlled by the strategy. WealthScript does not exit positions automatically or based on some priority. You declare it. Thus, I don't understand your concept. For sure, Cone knows better.

QUOTE:

Your "Sell Priority" is completely controlled by the strategy.

Correct. What I would like Wealth-Lab to do is sell the poorest performing position (based on Sell Priority) whenever Wealth-Lab finds a new position to buy in which there isn't enough buying power to otherwise purchase it. This way I'm rotating out the poorest stock when a buy opportunity comes along for a new (and hopefully better) stock.

In effect, I want to stay fully invested while rotating out the poorest stocks if there are stronger buys available. And I want to do this for all Wealth-Lab strategies. Why shouldn't this be the default behavior for Portfolio Simulation Mode?

There are some issues to consider. For example, "How much better should the new stock be performing before it displaces the old stock?" This needs to be set in the strategy code. There can be some tax issues. If the old position has only a month to go before it reaches IRS long-term status (15% gains tax), one may want to hang on to it until then. But this issue can be addressed when staging the sell/buy pair.

I'm sure you'll be able to code your idea for your own strategies. On how it's done in rotational strategies, here's an example of a pattern:

Rotation Enhancement: buy Top 3, sell when falls out of Top 10
ROC Symbol Rotation - Modification of the Strategy

superticker, I understand where you're coming from. Like Position.Priority, used by Positions added to a portfolio, you want the Portfolio Simulator to decide when to exit a Position in favor of a new trading opportunity. It's a novel idea, but it couldn't be added to Wealth-Lab's architecture without a major redesign.

The simulator works with raw profit mode Positions whose entry and exit dates are fixed by the strategy. The simlator always uses Position.Priority (whether random or not) to determine which trades are allowed to enter the portfolio based on available buying power. On the other hand, no priority is required to exit a Position, which always adds to buying power. Determining when to exit a position is simply not the job of the Portfolio Simulator; that must be controlled by the Strategy in the manner that Eugene has already suggested.

QUOTE:
... you want the Portfolio Simulator to decide when to exit a Position in favor of a new trading opportunity. It's a novel idea, but it couldn't be added to Wealth-Lab's architecture without a major redesign.

Understood; we are talking about a Wealth-Lab 7.0 version. I want to eliminate the buy priority (the Position.Priority the program employs today) and employ a new "sell priority" to help exit positions at the moment capital is needed to buy a higher performing position. I appreciate this default (rotational) Portfolio Simulation behavior requires some redesign since you're substituting one priority type (buy priority in the Position.Priority field) for another (sell priority) to manage the portfolio with.

QUOTE:
The simulator works with raw profit mode Positions whose entry and exit dates are fixed by the strategy.

That's part of the problem. In real-world trading, you're always rotating bad stocks out in order to buy stronger new stock positions. My position is that Portfolio Simulation Mode should mirror real-world rotational trading by default as much as possible. That's what's going to make us the most money. :-)

QUOTE:
Determining when to exit a position is simply not the job of the Portfolio Simulator

Agreed. The job of Portfolio Simulation Mode is to make the user as much money as possible with as little coding as possible. Do we agree?

To facilitate this, Portfolio Simulation Mode should support rotational trading as the default behavior where exiting positions is based on a Sell Priority set by the strategy.

But I totally agree, it's not up to the simulator to set this Sell Priority or determine by what criteria this Sell Priority should be set by. How to set the Sell Priority is controversial and can be approached in multiple ways. The simulator should steer clear of any controversy, and it has. That's one thing a really like about the WealthScript framework. Don't change that. The portfolio simulator should simply substitute the weakest position (determined by the Sell Priority set by the strategy) for a new stronger position (also determined by the strategy), and nothing more.

I'll take a look at Eugene rotational links (Thanks for the links.), but the one I studied slightly (It rotates Fidelity Select Funds.) is coded awkwardly because of some limitations of the WealthScript framework's architecture and the fact that C# doesn't support multiple inheritance. But honestly, I think C# is a nice language (and good choice) for WealthScript.

I'm more familiar with C++, which does support multiple inheritance, so I'm a little spoiled (and I know it). However, I think the complexities of C++ would turn off many WealthScript users.

QUOTE:
The job of Portfolio Simulation Mode is to make the user as much money as possible with as little coding as possible. Do we agree?

It's a good sales pitch, but I'd say the job is to perform backtests simulating real portfolio conditions as accurately as possible given the general constraints of backtesting / data.

While the idea is interesting, frankly Wealth-Lab's simulator is not a target for fundamental changes like deciding when to rotate positions in the portfolio. That would be a completely new product, not a Wealth-Lab 7.0 (or even 10.0).

QUOTE:

The job of Portfolio Simulation Mode is to make the user as much money as possible with as little coding as possible. Do we agree?

QUOTE:
... I'd say the job is to perform backtests simulating real portfolio conditions as accurately as possible given the general constraints of backtesting / data.

I totally agree, and finite buying power is one of those constraints. When you hit that buying power constraint, you can do one of two things:

1) Do nothing and ignore an opportunity to buy a new stronger position that would perform better than your weakest position.

2) Replace your weakest position with the new higher performing position.

In all cases, the more profitable choice will always be #2, and that's what the smart trader would always do. But if you want to simulate the dumbest trader, you simply don't set any Sell Priorities. In this case, #1 will be the only choice.

QUOTE:
Wealth-Lab's simulator is not a target for fundamental changes like deciding when to rotate positions in the portfolio.

It's not deciding, and it should not decide a controversial issue. It's the strategy that decides how to set the Sell Priority (and there are many ways to do that). And if no Sell Priority is set, then in works like it does now.

My point is that using this "rotation" (which is commonly performed in real-world trading) is up to the strategy, not the framework. The framework is only providing the strategy author an option to trade like a professional, but he doesn't have to.

It essential to give the strategy author a choice. I don't trade options, and Wealth-Lab doesn't require me to. But the ability to perform Short and Cover trades is still provided by the program. I just don't use them; that's my choice.

--------

Also, I don't think a major change is "required" to add a Sell Priority to the existing framework. Both Sell and Buy Priority (Positions.Priority) processing is now performed by the ByAtXxxx() call. It's an internal routine that may need to be extended to sell External Symbols, but that's something the so called "rotational strategies" are already doing with the current framework architecture. And with the ByAtXxxx() calls doing the selling of External Symbols (if Sell Priories are defined), the strategy author will no longer have to deal with External Symbols directly (an awkward operation).

It "might" be better to to exposed External Symbols to the WealthScript class in a new framework design, but that's certainly not a requirement. Moreover, I'm not so sure it's even desirable because you destroy some of the encapsulation. You really want the framework to protect the strategy author from those nasty External Symbols (if possible).

Maybe we both should give the (1) idea and (2) implementation more thought. Moreover, I'm interested in how other users feel about this proposed enhancement.

QUOTE:
Also, I don't think a major change is "required" to add a Sell Priority to the existing framework.

But you're thinking wrong. I'm trying to be frank about the fact that this is simply not a possibility and gave a good hint why it's not possible in my first post (#7): Wealth-Lab's simulator works with raw profit positions whose entry and exit dates are already fixed.

QUOTE:
Buy Priority (Positions.Priority) processing is now performed by the ByAtXxxx() call.

That's wrong too. [Buy] Priority is a property assigned (randomly by the simulator or deterministically by the Strategy) to a Position object. It is used by the Simulator to process the Position objects chronologically by entry date and then in order of priority. The lower priority trades are rejected if and when buying power is used up by the higher priority trades on the same date.

Your idea suggests that a Strategy effectively creates NO Positions and only assigns priorities to symbols, and then lets the Portfolio simulator decide when to buy and sell Positions based on the aggregate information. I hope you can now see that Wealth-Lab's simulator doesn't work this way, and that making a fundamental change to support a group of strategies that account for probably less than 1% of all strategies written for Wealth-Lab at the expense of the other 99% makes no sense - especially because you can already accomplish the task another way!

QUOTE:
Also, I don't think a major change is "required" to add a Sell Priority to the existing framework.

QUOTE:
But you're thinking wrong.... Wealth-Lab's simulator works with raw profit positions whose entry and exit dates are already fixed.

I guess I'm confused. I thought in Raw Profit Mode the priorities were ignored entirely. And that the priorities were only used in Portfolio Simulation Mode. Or are we talking about entirely different raw-profit behaviors?

Oh I see what you're saying ... "already fixed". The Positions object (symbols) is in the outside loop and the Bars object is in the inside trading loop; therefore, it's impossible for the trading of one symbol to be dependent on another. You would have to reverse the hierarchy of the two loops to make a dependency possible--interesting. But then, how could existing rotational strategies even be possible? (rhetorical) I'll have to study those rotational strategies in more detail; they must be doing something tricky to work. Clearly, I don't fully understand them.

QUOTE:
Buy Priority (Positions.Priority) processing is now performed by the ByAtXxxx() call.

QUOTE:
That's wrong too. [Buy] Priority is a property assigned (randomly by the simulator or deterministically by the Strategy) to a Position object. It is used by the Simulator to process the Position objects chronologically by entry date and then in order of priority....

Your idea suggests that a Strategy effectively creates NO Positions and only assigns priorities to symbols,...

Oh no, no; that's not at all what I'm suggesting. Sorry if I have been unclear. Let me clarify.

The authoring of the strategies would not change at all. There would still be the same entrance and exit code in the trading loop. That's not going to change. We want to maintain compatibility with all existing strategy code.

But outside of the trading loop, the strategy could (optionally) assign a Sell Priority to the current symbol based on its most recent performance. That Sell Priority would only be used by a future ByAt...() operation of a new symbol where there was an absence of buying power. In this instance, the ByAt...() operation would sell the poorest position (based on the strategy's Sell Priority assignment), and then buy the new higher performing position. For this special case, the strategy entrance code would execute the usual way, but the ByAt...() call would sell the old poorer position without executing its usual exit code.

But the problem is one symbol can't be sold in another symbol's trading loop with the current Positions/Bars loop hierarchy. You would have to reverse the loop hierarchy to make this work or do something tricky (e.g. two-pass simulation correcting the first (approximate) pass with the second pass). The problem is not the idea (it's a good idea), but the implementation. Preserving the current loop hierarchy is tricky.

I appreciate you patience in trying to understand my suggestion. Let me think more about the implementation part.