Kelly PosSizer generates strange results with a trading strategy using intraday (15 min) bars. My settings in the dialog window are:

2
30
80
25

It only trades for ~30 days with 1 Year data range, and then stops tradjng. The trade window indicates that there are 81 trades included and 677 not included due to insufficient funds.


I am starting with a $1 million portfolio and symbol is worth around $1,500.00 per share. The number of shares it trades gets nowhere close the the available cash limit.

The equity window shows plenty of cash available after 30 days. Don't know why it's generating insufficient funds warning and not taking trades.

Is this suposed to work with intraday trades?

The Kelly PosSizer stops trading because the position size reached is insufficient to take a new Position. I think this is because the Kelly criterion can get aggessive as a money management method. I don't see any connection to the bar scale used so you might want to try a much smaller fraction, max size allowed etc.

QUOTE:
The PosSizer stops trading because the position size reached is insufficient to take a new Position.

This is an interesting explanation I hadn't considered. In thinking about it, a minimum trade size of 1 "unit" must be taken at each signal, or the lookback Window will run out of data to generate the K value, and apparently terminate trading.

I played with the K configuration settings. They all seemed to have some effect, but I was unable to find a combination that would yield a completed run on 2-year 15-min data.

I suspect the Default% config value is only used at the start of the run, before the Window minimum # of trades has been met? (I.e., not as an override for too-small K values.)

At any rate, it's not clear why is it running out of money. There is plenty of cash to trade at all times.

Is there a way to read the K value, e.g. in the Debug window while it is executing?

I have attached screen shots of the results. Please let me know what else I can try.

On a related topic, I am taking both long and short positions on the same symbol. Does WL do separate calcs for Long and Short trades or combine into one value per symbol?

Thanks for the feedback.

QUOTE:
I suspect the Default% config value is only used at the start of the run, before the Window minimum # of trades has been met?

That's right.

QUOTE:
On a related topic, I am taking both long and short positions on the same symbol. Does WL do separate calcs for Long and Short trades or combine into one value per symbol?

The PosSizer does not separate long and short trades. The Kelly formula (which can be found in the Wiki) only takes closed trades into account.

QUOTE:
Is there a way to read the K value, e.g. in the Debug window while it is executing?

Not in the Debug window, only under debugger (read: we can do it). But if you could come up with a simple test case with demo Strategy code to demonstrate the anomaly I could take a look into it. Problem is, I don't have intraday data of that depth (I just don't need it neither for troubleshooting WLP/D nor for own trading) so EOD data would be welcome.

Thanks for the answers. It appears that a Min% value might help prevent this situation, unless Default% was used as a fallback.

QUOTE:
The PosSizer does not separate long and short trades. The Kelly formula (which can be found in the Wiki) only takes closed trades into account.

I understand that K calculates on closed trades. (Not sure if that was in response to my question or just some additional information.) Just to confirm, you are informing that the K PosSizer does *not* generate different values for Long and Short trades but only for different symbols? In other words, it is using the data that is showing in the *first* column of the Performance tab, "All Trades" for any type of trade on that symbol? Is there a way of "tricking" it to calculate separate values for L & S, e.g., by using proxy symbols (whatever that means) or tagging a position? L&S trades often have very different performance with the same strategy, at different times, and I am looking to use K to size them appropriately and independently, and ideally dynamically.

QUOTE:
But if you could come up with a simple test case with demo Strategy code to demonstrate the anomaly I could take a look into it. Problem is, I don't have intraday data of that depth (I just don't need it neither for troubleshooting WLP/D nor for own trading) so EOD data would be welcome.

I'm happy to send you something, but I'm curious. I'm simply using Fidelity 15 min. bars on RUT. You don't have access to the historical data that I do, or is there some misunderstanding? By Depth you mean timeframe (2 years?). The problem happens with months-long time frames as well.

The strategy is a very simple EMA crossing (Buy+Cover / Sell+Short) that I whipped up using the Rules Wizard. Happy to send it to you if I can locate the file. Do you want it?

If you actually don't have access to the same intraday data I have, is there a way I can send you the data in a file? I assume it's on my machine somewhere in the data folder.

QUOTE:
so EOD data would be welcome.

The problem doesn't appear with EOD data, so that's not going to be of any help to you. I suspect it has something to do with the fact that I am using intraday data.

Let me know if there's any other ways I can support your debugging.

I've made some testing and found the PosSizer's Window parameter to have inverse relation to the number of trades. If you bump it up from 30 to say 130 the number of dropped trades decreases drastically. I'm going to investigate whether it's a bug in the code or by design and get back to you. Thanks.

Here's what happens. The Kelly formula requires different parameters such as the number of wins and losses. Once a winning or losing streak occurs which is greater than the Window size, the PosSizer has to stop trading to avoid division by zero. Backtesting on intraday data highlights this due to a higher activity and more frequent streaks, be they winning or losing. Consequently, the workaround here is to increase the Window size beyond your system's largest winning/losing streak.

QUOTE:
It appears that a Min% value might help prevent this situation, unless Default% was used as a fallback.

You are probably right. But 1) I'm not sure if this is in line with the original formula and 2) introducing a parameter late in the game may break backward compatibility. As the workaround looks like a more suitable option to me, I've added a note to the Wiki.

Thanks for looking into this so expeditiously. Interesting stuff. I actually thought about this possibility overnight: that it wasn't a problem with i/d data per se, but rather that i/d trading tends to magnify streaks because there are so many trades happening on a single "bad day" or two or three in a row.

I was creating Kelly from scratch in code before I realized there was a built-in function. (Guess I should ask next time.)

I was wondering why my hand-coded solution didn't exhibit this problem. Then I realized that you had turned me on to a method a few weeks ago, where you do a run to get the data (that is normally in the Performance report), save it in a DataSeries (in this case the Kelly value for each bar) and then ClearPositions() and run the strategy again with conditions based on the DataSeries (Kelly value).

https://www.wealth-lab.com/Forum/Posts/Using-Strategy-performance-metrics-to-size-positions-39310

Because I did it this way, even when I got negative values for Kelly, I was still collecting data in my lookback window because trades that were going into the DataSeries were not conditional (kept executing without checking Kelly).

Something like this is necessary if Kelly is to continue to be accurate. If data starts getting based on trades that were filtered on Kelly, then we have a recursive situation. When any trade is rejected based on a Kelly filter (as opposed to the underlying strategy), the K value will no longer be valid.

As far as I understand, Kelly was not intended to be to be used with a moving time window for data collection. It wasn't intended as a trading indicator, but rather a probabilistic approach to money allocation. (Maybe you know all this already.) K Value can change over time, but that's only because new data is coming in (but not going out) with every trade. It seems WL, and I, decided to try to use it as an indicator.

So, since we're sort of in uncharted territory, what makes the most sense to me is that the system must capture the performance of each trade dictated by the basic strategy, if only to capture the data, before applying Kelly as a filter. It doesn't matter if the trader actually executes the trade. Kelly is agnostic to the size of the trade since it deals with ratios and percentages, not absolute dollars.

QUOTE:
It seems WL, and I, decided to try to use it as an indicator.

In a PosSizer there's simply no alternative to using rolling K value. If it were calculated for all the trades of a backtest (like a static figure on the Performance tab) then how could it be applied to trades in the beginning or in the middle? That would be peeking as you well understand.

QUOTE:
So, since we're sort of in uncharted territory, what makes the most sense to me is that the system must capture the performance of each trade dictated by the basic strategy, if only to capture the data, before applying Kelly as a filter.

PosSizers process trades sequentially. What you're proposing might imply a rewrite of the Kelly PosSizer core logic.

Right. I understand. Given these constraints it seems to merit a very large lookback window with long data period. I don't know if anyone has proven that recent market action within some dynamic time window is predictive of optimum trade size. I certainly haven't been able to.

BTW, I was thinking about the way K algorithm works: it is not necessary for trades to be losses for K to go < 0. It can happen with a combination of weak (< 2.0) Payoff Ratio and Win% (<40%). In a way, K is informing that the historical performance indicates a poor risk/reward strategy, which has a high chance of going broke if positions are taken or are too large. As I mentioned before, it would normally be applied to a historical dataset to inform long-term trading size, so it starts out as a static number that can change gradually over time.

I think there would still be value in generating a static number as a starting point, together with performance metrics. This can be done today by copying the Performance data into a spreadsheet and calculating the formula from the Payoff Ratio and Win% numbers.This method can calculate individual sizing values for Longs and Shorts when done in a spreadsheet, because the Performance Report breaks out individual performance for each type.

K could be a value listed in the Performance Report (by trade type and combined) or in an Extended Scorecard (combined). Just my thoughts...