Enhancements to The Grid

Some new additions to The Grid:



+ The Grid remembers your “filtering” preferences. (But it does not remember the way you have sorted columns; that will come soon.)



+ Now you can use The Grid to evaluate how many points the system typically earns per futures contract, or how many cents per stock share, or how many pips per forex trade. This strips away the quantity traded, and shows you how much gain or loss you can expect per unit, per trade. In addition, you can further break this down by common futures symbols. For example, you can ask how many @ES points a system makes for each @ES trade.



+ I fixed the bug in which systems that traded even negligible amounts of options would disappear off The Grid if “options” were not explictly checked. Instead, there’s a 10% threshold. If 10% or more of the trades are options trades, for example, then the system will appear when “Options” is checked, and will disappear when “Options” is unchecked.



As always, this is a very early release. I tested it for a little over 12 minutes. Set your expectations accordingly.



Soon-to-be-added: I will try to make The Grid remember column sorting status.



Let me know what you think.



Matthew

Thanks Matthew!

Collective2 surely is always a top notch website, thanks for the recent improvements.



Enjoy the Super Bowl-

-David

Under "Analyze P/L per quantity unit?"



when selecting a futures symbol, the radio button for Futures symbol should automatically select.


Matthew:



You are using "P/L Per Unit" in this calculation. This is not profit per contract, as has been brought up many times on the forums, and is not even close for many systems.



As of today 2/4/07, "Short-Term Stock Index Program" has traded 787 contracts, and has a profit per contract of $71.17 or 1.42 ES points per contract.



The Grid shows .814 ES points per contract, which is the "P/L Per Unit" number, and has nothing at all to do with profit per contract.

The calculation simply strips away quantity from each trade and asks how many points each trade makes (if only one contract were traded). Then it averages these numbers.



I’m not sure I understand your distinction between per contract and per unit, especially when a contract is the unit.

I think that Dustin refers to the fact that if a subscriber trades 1 contract on each trade, and the system makes a trade with multiple legs, then the subscriber’s profit will not be equal to the system’s total profit on that trade divided by the system’s number of contracts in that trade. The last statistic is displayed by C2, but it does not apply to that subscriber. Also, if the subscriber is an autotrader who set min and max to 1 contract, then this will be applied to each signal, so he will buy or sell 1 contract on each leg, which would still yield another profit figure.

Is it possible that different instruments were used for diff trads, scaling in/out or variable-sized trades are somehow effecting this?



I remember sometimes getting strange effects when doing somthing similar to this for other purposes. It is not always as easy as it seems on the surface…

Yes, a contract is a unit.



The way you calculate "P/L Per Unit" does not give the profit per contract (or unit) for systems that scale into or out of trades.



Look at my example. The "P/L Per Unit" is nearly one-half of the actual profit per unit.


Profit Per Unit should be: Total Profit Per Symbol / Total Units Traded That Symbol. THEN average together the results of the various symbols for the “P/L Per Unit”. Currently you’re skipping the first step and calculating the average on a per trade basis, which skews the math badly for systems that scale into/out of trades.



It’s not only a problem for systems that scale in an out of trades. ANY system that trades a different amount of shares per trade will be affected (i.e. almost all systems).



To see this, consider a system that does just 2 trades:



trade 1: 1000 shares, total profit $1000

trade 2: 1000 shares, total profit $1000



In this case, it doesn’t matter how you calculate P/L, it’s $1/share.



Now, suppose trade 2 would be 100 instead of 1000 shares, but still has a $1000 overall profit:



P/L per unit (C2): (1000 / 1000 + 1000 / 100) / 2 = $5.50

P/L per unit (Dustin): (1000 + 1000) / (100 + 1000) = $1.81

Except that I still think the number C2 is showing here is valuable. For a stock-trading system, it says: “How many cents, on average, does a share gain when I buy it long?” (Or how many cents does a share decline when I sell short?)



Useful information, no? Doesn’t that let a subscriber know whether a system typically profits from big moves or, alternately, aggregates lots of tiny 2-cent moves? (And the latter, of course, would be much more likely to be eaten by slippage.)


Unfortunately the way it’s being calculated doesn’t have the effect you’re looking for.



Currently, when you take a larger than average position your “P/L Per Unit” will go down unless that trade’s profit is larger than the average profit.



In trading, this is almost never the case. Usually, you will take larger positions when volatility is low in order to offset low volatility (also because there’s less risk). Currently, correctly adjusting position sizes in this manner kills the “P/L Per Unit”. Incorrectly INCREASING position size when volatility increases drastically inflates the “P/L Per Unit” figure.



In short, currently the figure rewards what most would consider bad trading, and punishes systems that correctly adjust size based on market volatility.

Well, I think you get unintuitive results with the current way. If one of the trades in the example I gave has a loss of $1,000, the cumulative P/L of the system would be zero, but the P/L per unit would be different from zero. I think that could possibly confuse subscribers.

Finally, your thoughts about slippage don’t apply.



There is no more accurate way to gauge the effects of slippage than to apply them to a true $ per share figure. $ per share - slippage per share = what you’ll end up with.

Upon reflection, I think you are right. I will change the math accordingly. Probably will be done within 48 hrs. - MK

Matthew, I am not sure whether or not this is the same issue, but at least for stock systems, the average $ P/L per share is not meaningful without weighting each stock by of the percentage of total portfolio capital allocated. The %P/L per share per % of portfolio capital is what matters.

MK, if you are going to do this, I suggest that you account for trade ordering (sequence of the trades) effects with Monte Carlo analysis. If the statistics are compiled for each sample of the Monte Carlo simulation, they can be stated in terms of the Monte Carlo simulation results. The effect is that a confidence level will be added to each statistic, which will make the results even more useful.



This is needed because some of the statistics depend on the order (sequence) of the trades; for example, the P/L per unit figures, number of consecutive losses and the drawdown statistics except when one-contract position sizing is used in the calculations as is done currently; otherwise the statistics would be misleading. Until this Monte Carlo analysis simulation results are available, I suggest that you retain the current P/L per unit calculation.

Once you begin weighting by quantity, you might as well just use the actual dollars of profit per trade.



The point of this statistic isn’t to be a perfect, all-encompassing statistic which measures a system in all all its facets; rather, it’s simply a quick stats designed to be a rough measure of whether the system “scalps” and goes for lots of little gains, or whether it holds for larger movements of the instrument.

I agree. If that is the point of this statistic, I see no need to change the way the current P/L per unit calculation. The way the current calculation is done, it captures the point you made perfectly. Kudos to you for providing this very vital statistic (reminds me of Vitalstatistix - a chief character in Asterix and Obelix comics :slight_smile:

I understand, but at least putting the stat on a percentage basis would be much more meaningful and the current $ basis. For example if shares are $25, a $0.50 P/L is much closer to "scalping" than a $0.50 P/L on a stock that is $3 per share.