This is a very interesting strategy, but I'm having problems with it in simulation mode. The code does not seem to invest the full position size in certain cases.

Here's a simple example: I'm using the parameter set (40, 15, 100,3) on the Nasdaq 100 daily for the last six months. I'm using a position (fixed dollar)size of 10,000 and starting capital of 10,000. Here's an excerpt of what I get from Weath-Lab:

QUOTE:

PositionSymbol QuantityEntry Date Entry PriceExit Date
Long GOOG 6 08/27/10 452.56 10/19/10
Long GOOG 5 08/27/10 452.56 09/22/10
Long GOOG 6 08/27/10 452.56 09/14/10
Long GOOG 5 08/27/10 452.56 Open
Long CTXS 42 10/07/10 61.03 10/28/10
Long APOL 66 10/15/10 37.94 12/09/10
Long ERTS 159 10/19/10 15.6 11/09/10
Long FSLR 19 11/02/10 134.42 12/13/10
Long GENZ 35 11/09/10 71.03 11/26/10
Long TEVA 51 12/06/10 49.28 12/10/10

Notice that the last 6 positions (excluding GOOG) invest only 2500 instead of the 10000 specified.

When you set starting capital equal to your position size, it at first creates the equivalent of having 100% equity invested in the trade. Look at how many positions were skipped due to capital constraints ("Trades not included..." on the status bar of the Trades tab). Due to the way Wealth-Lab is designed, properly executing a system with pyramiding rules on a portfolio of instruments in portfolio simulation mode can get a bit tricky.

To quote the Pyramiding PosSizer online help page:

QUOTE:
Without this PosSizer, Wealth-Lab's real-world simulation rules can skip the initial entry signal due to insufficient funds, but your system will be entering pyramided trades like nothing happened. This PosSizer will skip all additional entry signals if the initial trade has not been taken.

I think this is what could've happened with those trades: the pyramid "base" was not established but the addin trades were taken. Suggestion: try the Pyramiding PosSizer.

FYI: Please discuss published strategies in their own forums. To do it, click the link titled "0 Topics" in the "Discussions" column to enter the strategy's subforum, and there you can start a new discussion thread.

Eugene, the RSI Scale Out system doesn't pyramid. It buys a single position and then splits to scale out.

What appears to be happening above is that not all $10K is available for new trades. Take GOOG, which still has a position open. It exited half the Position before October, leaving about $5K for the CTXS trade on 10/7. Still, I'm not sure why only about $2.5K was used for that trade. Let me run it an take a closer look.

I get this error when I try to follow your directions and continue the discussion under the appropriate strategy forum:

Unknown Error
Please try again later. If the error remains unsolved please contact info@wealth-lab.com. We apolgise for the inconvenience.

So I will have to continue here. It is not clear to me how to configure the PosSizer in a way appropriate to this strategy. I want all entries to be 10000. Depending on the exit the strategy takes, there could be the following exits: A: one exit of all shares; B: one exit of 25% of the shares, a second exit of 75% of the shares; C: one exit of 25%, a second exit of 25%, and a third exit of 50%; D: four exits of 25%.

So what is the proper configuration of the PosSizer for the above scenario?

I see Cone made a post while I was composing mine and I did not see it. I will wait for Cone's result after he takes a closer look.

Well, something doesn't look right, and it could be (just conjecture at this point) a symptom of problem we already have under investigation - that the PosSizers are not always getting the correct Equity value to size.

Back to the backtest above, since GOOG always had a 1/4 position open, there should have been no other trades since you've specified $10K lots and there was never more $5468 in cash available for new trades.

There is a caveat. Even though you requested a $10K lot, the PosSizer could be programmed to use any available cash to add new Positions, even if it is below the specified dollar size. (I'll check on that.) In that case, I still would have expected a lot with a dollar size near $5468 for the CTXS trade, and since it was closer to $2560-ish, there's still a problem.

We'll take this as a bug, at this point.

OK. Thanks. Looking forward to the outcome of your investigation.

After looking at this some more, Eugene's line of thinking was correct...but it's sort of "reverse pyramiding". In other words, when pyramiding, you're establishing separate lots of Positions over time. Splitting has the same type of effect, except that all of the split Positions are established on the initial trade date.

So here's what's happening:
Wealth-Lab runs the Strategy on each symbol, adding the Positions to a composite list. At the end of the backtest, that list is composed of all the *separate* Positions that have been split. Consequently, while building the equity curve and during the sizing process, Wealth-Lab is picking up parts of the Positions that were split in the Raw Profit runs. That's why we're seeing those 25% single lots of CTXS, APOL, and others.

Eugene's Pyramiding sizer will work to some extent, but there are 2 problems, one with the script (even Rev C.), and the other with the ability of the sizer to choose between initial trades that occur on the same bar:

1. Script: If you split a Position, you have to make sure that you change the .EntrySignal property of the split positions so that the Pyramiding PosSizer can do what was intended. This is done in the script's edit below (call it Rev D.).

2. Sizer: When you run "Rev D." with the Pyramiding PosSizer, you'll see 2 trades - GOOG and ISRG, splitting the $10K 25% and 75%, respectively, on 8/27/2010. That's the remaining problem - both "initial" trades occurred on the same day. Despite GOOG having the .Priority with a higher Close value, for some reason the Pyramiding sizer isn't allowing those other 3 split trades through, which allows ISRG to be sized. (Eugene, you can verify that just by running the script on GOOG alone.)

CODE:
Please log in to see this code.

imho, Wealth-Lab should fix this. It seems this should be possible by simply recognizing the full size of the initial Position when sizing. The problem may be to determine that a Position is part of a split group... I don't think that Position property exists yet.

I've got Rev. D running. How do I access the Pyramiding PosSizer? I've downloaded the Community Indicators library.

Click "Extensions" on this site, find there and install the MS123 PosSizer Library.

I've got the Pyramiding PosSizer installed. Cone said,"2. Sizer: When you run "Rev D." with the Pyramiding PosSizer, you'll see 2 trades - GOOG and ISRG, splitting the $10K 25% and 75%, respectively, on 8/27/2010. "

How do I set up the Pyramiding PosSizer to get this result?

Well, the result is still wrong, but if you want to do it anyway, just click "Configure..." put 10000 for the fix Dollar, and if it's not already there, put "initial" in the Initial entry signal.

Keep in mind that if you've updated your data, your "most-recent" 6-month window is moving. You'll need to set the Date Range to start from 6/28/2010.

OK, I took 10000 fixed dollar, 25% size of pyramid entry, and 4 as number of pyramid entries and got Cone's result!

So the only problem left is that GOOG is not 100%.

After seeing Cone's reply, I took 10000 fixed dollar, 0 for pyramid entry, 0 for number of pyramid entries, initial entry signal and again got Cone's result.

I'm afraid there are still other problems: I ran Rev.D with the (40, 15, 100,3) parameter set and the above pyramid PosSizer on 7 years of Nasdaq 100 data, and got no exits which were not timed or stops.

I see some "RSI 55" exits, but the result is unpredictable due to the reasons we've discussed. If you want to see all the trades and exits as they would have occurred if you had unlimited cash, just switch to Raw Profit mode with your $10K sizing.

OK That's what I've been doing. The Raw Profit mode seems to be working fine.

QUOTE:
Well, something doesn't look right, and it could be (just conjecture at this point) a symptom of problem we already have under investigation - that the PosSizers are not always getting the correct Equity value to size.

Nope, seems like in this particular case the equity value isn't to blame. What I observe when debugging Rev.D on GOOG alone starting from 06/28/2010 are the following four entry signals:

* "split 2" and "split 3" which are rejected immediately because no pyramid base could be found (by design),
* "initial" and "split 1" are accepted (as expected).

The reason why it happens IMO is the Priority assigned to these SplitPosition parts make them appear in this particular order in the PosSizer (and get rejected). If I manually assign a double value like this, they get sized properly:

CODE:
Please log in to see this code.

OK, Eugene, I have been using several versions of this script in raw profit mode and did not notice your last post of 2/23/2011. I made the changes suggested, and the scripts now seem to work in simulation mode. Thanks!

The only problem I have with this script now is that it provides fractional share buy and sell orders which I have to manually edit to be integral shares.

How can I edit the script so that it produces only integral share buy and sell orders.

Could you clarify what are you talking about?

OK. Below you see the first three alerts the script gives me when I run it on the IBD 50. Note that it tells me to sell 64.731654814253 shares of AMCX. I have to manually edit this order to read sell 65 shares of AMCX. I want to know how to alter the script so that it will tell me to sell 65 shares of AMCX automatically. And the same comments apply to the rest of the alerts. Note that these fractional share alerts only happen after a scale out has occurred and part of the stock holdings have been sold.

Alert Time Symbol Account Action Qty Order Type Price Scale Signal Name Trade Type Strategy Name
11/14/2012 AMCX xxxxxxxx Sell 64.731654814253 Stop 31.69 Daily Stop RSI Scale out Rev.D
11/14/2012 ANV xxxxxxxx Sell 98.222163482631 Stop 18.82 Daily Stop RSI Scale out Rev.D
11/14/2012 ARMH Xxxxxxxx Sell 102.47095935847 Stop 20.79 Daily Stop RSI Scale out Rev.D

Thanks, I see. Looks like a SplitPosition something. I replaced the PosSizer with standard Pct Equity, replaced the fractional SplitPosition parameter to an integer one, and still get fractional shares. It's not the RSI script thing because the effect can be reproduced even with a generic SplitPosition code like this:

CODE:
Please log in to see this code.

Let's investigate.

p.s. Position size is inherently a double value in Wealth-Lab. What's not clear is what role SplitPosition has in it, given that most PosSizers naturally produce fractional shares which always get rounded.

Carova wrote in a duplicate thread:


Hi Eugene!

I was looking over the code for ActiveTrader 2010-02 | RSI scale-out system Rev.C and was exploring this piece of the code

CODE:
Please log in to see this code.

What is the purpose for the following code?

CODE:
Please log in to see this code.

Thanks!
Vince

Vince,

Obviously this is assigning Position.Priority as per the QuickRef. For more insight please study this thread. Seems like it even includes a [Rev.D].

Hi Eugene!

Thanks! My question was not about this script per se, but rather why is the Position.Priority required on the Sell?

I was reading the thread and I saw this that you posted in post #17.

How would I assign a Priority to the Buy using an indicator in this situation?

Vince

Hi Vince,

QUOTE:
why is the Position.Priority required on the Sell?

No, that doesn't make sense. Position.Priority here, and anywhere else, is assigned to a new Position - in this case to the remainder of the Position established by SplitPosition.

QUOTE:
How would I assign a Priority to the Buy using an indicator in this situation?

Appreciate your curiosity but here we're dealing with a live bug, probably deferred:

Open Issues > (7282) SplitPosition() does not interact realistically in Portfolio Simulation Mode

So what you see is a workaround to the bug. Hope it answers your question.

Thanks Eugene!

BTW, this is a 5 year old bug. Is there some indication when this and some of the other old bugs might be resolved? 5 years is a long time in the SW world.

Vince

Vince, an indication is in my reply: "probably deferred" a.k.a. WONTFIX, meaning "a snowball's chance in hell" for all practical purposes.

Got it! ;)

Hi there,
I had a closer look at the strategy including Rev.D, but also have a question regarding the exit of positions, which I cant explain myself.
If I use the strategy in combination with the D-VAR-possizer or Percent Volatility PosSizer and I configure a huge risk (see screenshot, 20% risk on 100 bars), so that it usually takes only one position and doesnt split, it all the times sells at different RSI-levels (besides 30.09.1083 in the example).

However, it does it really smart, like it knows, that prices will move higher, and keeps the position until the highest RSI-level is reached.

I thought in the beginning, it is because there arent any other stocks to trade with specified risk, if I use the strategy on multiple symbols, but it also happens if I just run it over one security.

I tried manually to figure out the risk/volitiltiy levels, when it reaches the first RSI-barrier, but it seems there arent any differences, when it decides to sell or to keep the positions.

It seems there is something hidden in the split-logic, which is not visible from the code in the strategy, because when I deactivate the can split with

CODE:
Please log in to see this code.

, it always sells at the first RSI-level.

Any ideas, why it happens?

Hi Sebastian,

Before you employ or troubleshoot this strategy (coded a decade ago and affected by a live bug in WL), please double check that you've read everything written here before. Make sure there are no skipped trades as you have too much of them currently for it to work correctly.