R-Multiple Graphs Feature / Reposted

Discussions about the testing and simulation of mechanical trading systems using historical data and other methods. Trading Blox Customers should post Trading Blox specific questions in the Customer Support forum.
Post Reply
stamo
Roundtable Knight
Roundtable Knight
Posts: 522
Joined: Tue Mar 13, 2007 5:27 pm

R-Multiple Graphs Feature / Reposted

Post by stamo »

The following post was originally put in the " Trading Blox Support" forum but I realized that not everyone has access to that.

MOD: Link to original posting: viewtopic.php?t=5076

So I am reposting it here for broader access.

Original Post follows:

//////////////////////////////

I’ve come across an interesting feature of the R-Multiple Distribution & Profit Contribution Graphs.

It wasn’t obvious to me at first and I thought it might be helpful to point it out.

The feature became apparent to me in simulations where there were high R trades that were trimmed in size many times by risk management as they continued to increase in value.

The feature is that each trim ‘created’ a new trade (OK, no surprise). And each ‘trim’ trade added one observation to the R-Multiple Distribution graph with the trim trade’s R value going into the R-Multiple Profit Contribution graph.

So if you have high R trades and lots of trims to manage risk, then your R graphs may ‘look’ much better than a very similar system without trimming.

***

Here’s an (extreme) example to illustrate:

Case 1: System has one trade: one entry and one exit that is high R and no risk management via reduce positions. R graphs have one bar each. See ‘Case 1’ image.

Case 2: Same system, same entry date & size but add risk management by reducing positions. This time we have 29 small trims to manage risk plus the final sale. See ‘Case 2’ image.

The CAGR and final equity of Case 1 & Case 2 (not shown) are fairly close so I would consider the two similar in many respects.

***

Here’s why I’m bringing this up:

Let’s say you have a much larger simulation with many more securities and it has mediocre results.

If you add Case 1’s single trade to this system’s R graphs, you probably won’t think there is a lot of change. Nice to add that one high R trade but probably nothing earth-shaking.

But … if you sprinkle Case 2’s 29 high R trims and final sale into the mediocre system’s R graphs, they could easily make it look like a great system.
Attachments
CASE 2
CASE 2
2008-03-19 TB R Case 2.PNG (55.95 KiB) Viewed 5999 times
CASE 1
CASE 1
2008-03-19 TB R Case 1.PNG (51.37 KiB) Viewed 6001 times
stamo
Roundtable Knight
Roundtable Knight
Posts: 522
Joined: Tue Mar 13, 2007 5:27 pm

Post by stamo »

In the post in the non-public area sluggo replied (in part):

"I think you may be expressing disappointment that R multiples (Rm = Dollars of Profit / Dollars of Risk) don't necessarily have the same denominator in every case ..."

and I replied:

Thanks sluggo - that was the unstated point of my post:

Don't assume that the observations in your R-Multiple Graphs have the same 'weight' or denominator.

But isn't some sort of common size or weight precisely the point of using R-multiples !?!
Chuck B
Roundtable Knight
Roundtable Knight
Posts: 481
Joined: Thu Apr 17, 2003 6:34 am

Post by Chuck B »

I originally defined an R-multiple not in terms of dollars but in terms of market points. I then used risk based position sizing on those market points of risk in the R (i.e. a fixed percentage of the current account equity). Hence no matter the size of the risk in market points, the risk to the portfolio per trade was identical. That was the main initial point of an R-multiple...to get away completely from favoring one trade versus another in terms of their risk profile.

I have no idea what Blox is doing creating all those additional R's as you mentioned. That makes no sense to me at all. When I evaluate a system's result, there is only one R per entry. Since there was only one entry in this case, there should be only one R.

Now if you want to add some complexity to it (i.e. scale-ins), I consider each additional scale-in as a separate trade with its own associated R and its own position sizing rules.

Does that make sense? Again, I don't have any idea what Blox is doing as you have described it as it sounds a bit whacky.
sluggo
Roundtable Knight
Roundtable Knight
Posts: 2987
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo »

Um, Chuck, Blox is just considering each scale-out as a separate trade. Which is, at very least, symmetric with your consideration of each scale-in as a separate trade.

Let's talk scale-ins for a moment. If our OP's system sometimes enters a full size position, and other times scales-in with up to 5 pieces (each piece being 1/5th of a full size position), Blox will consider these to be 6 different trades and will weight them equally in the histogram of R-multiples. That's what bugs our OP: the fact that the full-size position is equally weighted with each of the (1/5th) size scale-in positions.
Chuck B
Roundtable Knight
Roundtable Knight
Posts: 481
Joined: Thu Apr 17, 2003 6:34 am

Post by Chuck B »

sluggo wrote:Um, Chuck, Blox is just considering each scale-out as a separate trade. Which is, at very least, symmetric with your consideration of each scale-in as a separate trade.
No, it's really not. The whole concept of an R-multiple as it was created (I created the thing, so I should say my concept) was 100% related to entry risk ticks versus trade exit ticks captured. What has been done here is confusing position sizing, risk management, with the underlying mechanical system rules. The only way to calculate the R for a given trade is to use the net total ticks captured once the overall exit is hit and compare that to the initial risk ticks.

I use risk scaling-out all the time, but I don't confuse that portfolio level risk management with the underlying system's design. Perhaps it would be best if Blox threw out those incorrect R's into a different graph, etc, so as not to confuse the user. That way you could more easily understand what is "underneath" those displays of R's; otherwise, it is almost meaningless imo.

Scaling-in is a different story since now you are creating a new entry into a given market. If you create a separate system the perfectly recreates your scaling-in entry and exit, it should be able to stand alone on its own merits. After all, a scale-in is a separate system in my mind. You simply have the initial constraint of a trigger based on the rules of the main, initial, system.
stamo
Roundtable Knight
Roundtable Knight
Posts: 522
Joined: Tue Mar 13, 2007 5:27 pm

Post by stamo »

Correct again, sluggo. My concern is that the full-size position is equally weighted in the R-Multiple graphs with each of the tiny risk-trim positions.

In Case 2 above, the 29 tiny risk trims get the same weight in the R-Multiple graphs as the massive remains of the original trade.

This could easily confuse some users into thinking they have a much better system than they really have. It certainly did to me until I dug in.

The tip-off that something was up was the sudden appearance of a massive spike out in the 15+ R bar of the contribution graph when risk mgmt with reduce positions was added.

Going from Case 1 to Case 2 it was a sudden shift from 17R to 240R. In systems with several high R trades the shift can be much higher.

The spike was so out of place it was hard to believe it was real. (Although I really, really wanted to believe it was real - I had the 500' yacht and Agusta helicopter with matching paint all picked out.)
Last edited by stamo on Wed Mar 19, 2008 3:50 pm, edited 4 times in total.
Chuck B
Roundtable Knight
Roundtable Knight
Posts: 481
Joined: Thu Apr 17, 2003 6:34 am

Post by Chuck B »

Sounds like it's time for a programming change to reflect real R-multiples.
stamo
Roundtable Knight
Roundtable Knight
Posts: 522
Joined: Tue Mar 13, 2007 5:27 pm

Post by stamo »

A few comments:

sluggo: Thanks for helping to clarify what I was getting at - your posts on this board are always good to read.

Chuck: Thanks for reminding us of your 'original intent' of what R is.

Here are a few potential ways to address this issue.


(1) Do nothing. I get the feeling the users on this board are pretty sophisticated - if this is the first time this issue has come up then on a 'per user' basis it's probably not very important. During sys dev, turn off risk mgmt via position reduction - the R graphs will be useful. During production, turn it back on if you wish and ignore the R graphs.


(2) See sluggo's first comment in the original post (now locked) here:

viewtopic.php?t=5076&highlight= and reproduced at bottom at "**"

sluggo's idea seems like a pretty good fix to me.


(3) Use simple filtering out. Just as we have results filtering in large sim reporting, implement some filtering on which trades go into the R-Mult graphs.

Looking at my trims, the initial position was 3,091 shares. The largest trim was 230 shares. So a filter on any trim that initially was less than 8% of total initial trade size would remove all trims from the graphs. If you know your scale-ins are never less than 20% of initial trade size then a 19% filter would probably catch most everything. (Yes, scale-ins are separate trades and would never be included in this - I'm just thinking of easy to understand thresholds.)

Also, use this trade filtering on other calcs such as Monte Carlo sims. Using Case 2, above, I don't think we would want the 29 high R tiny trades to be part of any equal-weighted simulation.






** in original post sluggo wrote:

I think you may be expressing disappointment that R multiples (Rm = Dollars of Profit / Dollars of Risk) don't necessarily have the same denominator in every case. Trade entries that are paired with a single exit (trades that don't get "trimmed" in your terminology) have a large denominator, while trade entries that get split into many trades due to many different exit points ("trims") have small denominators.

You could of course define your own measure-of-goodness which has, by definition, the same denominator in every case. An example that seems sensible to me, is the "Percent Profit Factor" calculation built into Blox. This is a ratio

PPF = 100 * (dollars of profit on the trade) / (Account equity dollars on the day of entry)

You could define the numerator to be "total dollars of profit on all pieces of the trade including scale-ins and scale-outs and trims and pyramids" if you wished. Now you get the same numerical result whether or not Blox schmeers the entry and exit over many little pieces. Which, it seems to me, is approximately the way you wish that Rmultiples were counted.
Post Reply