Julian’s Journal

[Anonymous]

Hmmm that stinks.

I was thinking about this more.

The lossy trades, you are definitely going to get filled because yesterday’s close is at 10, you set limit order today for 8.65, price gaps down or travels down during session to this limit and keeps sinking for the day, closes at 8.30, you’ve definitely gotten the fill as it spent loads of time below your limit price and hey presto you banked a loss for the day.

For the potential profitable trade, previous close at 10, set limit for 8.65, price opens at 9.50, fluctuates around a bit then at some point JUST touches 8.65 for a fraction of a second. The 3,000 unit order gets a 600 unit partial fill, the rest goes unfilled. Close at 9.10 for the day and Amibroker believes you got the full 3,000 unit fill and you made 1,350 whereas you only made 270. Or worse still, Norgate/Amibroker see a 8.65 Low and you got a zero fill.

I think in our efforts to maximise profits through backtesting/optimising we are always going to take the most profitable, least drawdown results/settings. But this in itself will always lead to this problem as in my mind, the most profitable trades/systems/settings are always going to have the trades that are right at their most extreme of our settings, the trades where we very accurately hit the low of the day.

How to circumvent? I was thinking of how to add a -1% buffer of sorts to the low price target of the day and only upon hitting the -1% buffer limit price does the backtester assume a fill at the original, non -1% price.

Something like previous close at 10, limit set for 8.65, backtester will only pass a successful fill through to the trade list if Low of the day hits 8.50, yet it passes the trade through to the trade list at a fill of 8.65, not at a fill of 8.50. If the low of the day only gets to say, 8.58, then it assumes you did not get the fill and trade would not make it through to the trade list.

I reckon this is the part of the code to play with in custom backtester to make it work:

if (sig.IsEntry() && sig.IsLong())
{
SigCount++;

LimitPrice = StaticVarGet(sig.Symbol + “LimitEntryPrice”);
LowPrice = Foreign(sig.Symbol, “Low”);

// Restrict number of orders per day
if (SigCount > MaxOrdersToPlace OR
SigCount > DailyEntryOrderLimit)
sig.Price = -1;
else
TotalOrdersPlaced++;

if (LimitPrice < LowPrice)
sig.Price = -1;

}

Probably need to fiddle with the LimitPrice and LowPrice arrays, add another metric with percentage etc, perhaps also the LimitPrice if statement.

It would also make sense to pass through a successful fill to the trade list if the close for the day is below the original limit price but above the -1% overrun. This will help with accurate losses/drawdown, but always keep a buffer for perhaps/maybe more profitable CAR in real time trading than what we see in backtests.

Is -1% overrun too much? Too little? Obviously you would need to make the right balance, as wild settings like -10% would completely block every trade and make the system pointless. And wanting a fill at 8.65 and only expecting to get the fill if price drops to 8.50 could still face the same problems, because a quick, one second price spike down to 8.65 with no fill could probably happen just as rapidly as a quick one second price spike down to 8.50 with still no fill at 8.65. Still, I would like my chances better if I have chosen results/settings knowing there is a small buffer that can possibly help me with this problem, if at all.

Whilst we are on the wrong side of the problem, I reckon it makes sense to try. Imagine the day we are all sitting here saying “my real time trading results are better than the backtested results!”. Certainly better than current 9.39% expectation and 5% reality.

I’ll give the knobs a twiddle and see if I can come up with anything positive.[/i][/i][/strike]

[JulianCohen]

I’ll pass the idea to my programmer and see what he says. The code in the CBT is quite weighty and fiddling with one thing might affect something else.

I’ll let you know what he says.

[LEONARDZIR]

Here is how I handle my limit orders. I don’t place my limit orders in the market. The software I am using holds the limit order and places it in the market when the limit price is hit. In addition I can specify a percent of slippage I’ll allow which means I get most fills but some fills will be above the limit price(if long) depending on how much slippage I allow in the system.
That said I am still not very profitable using my current MR systems.

[Anonymous]

Oh well that was simple enough.

Added this to parameters….
LimitOverrun = Optimize(“Limit Price Buffer”,0.20,00.0,1.00,0.01);

Altered this line in the CBT code….
//LimitPrice = StaticVarGet(sig.Symbol + “LimitEntryPrice”);
LimitPrice = (StaticVarGet(sig.Symbol + “LimitEntryPrice”)) – ((StaticVarGet(sig.Symbol + “LimitEntryPrice”)) * (LimitOverrun/100)) ;

Explorations stay the same.
Backtested results differ, seemingly honouring the buffer correctly. That is, the low price of the day has to be below the limit price minus the percentage before it will assume it gets a fill, and the fill is at the original limit price, not the limit price minus the buffer, which is perfect.

Even just 0.2 of a percentage point buffer seems to knock profit off. Under my example earlier at 8.65 limit buy, that would mean the Low of the day would need to drop below 8.6327. Not really much of a difference, just under two US cents. AND, with that in play, a quick backtest of one of my systems showed profit drop from high 20’s CAR to low 10’s. What a difference a few cents can make!

[Anonymous]

I changed it to the following…..

LimitOverrun = Param(“Limit Price Buffer %”,0.10,0.00,0.50,0.01);
LimitOverrunMax = Param(“Limit Price Buffer Max $”,0.10,0.00,1.00,0.01);

LimitPrice = (StaticVarGet(sig.Symbol + “LimitEntryPrice”)) – Min( ((StaticVarGet(sig.Symbol + “LimitEntryPrice”)) * (LimitOverrun/100)),LimitOverrunMax);

Simply because it is not very practical to keep the percentage the same on the higher value symbols. If you’ve set the buffer to 0.1 % that makes sense on the $10 symbols, because that is just a 1 cent buffer. But if you’re trying to buy TSLA at $600 you don’t need a 60 cent buffer. On a $50K position you would be just 83 units volume. If IB can’t quickly fill an 83 unit order within 60 cents of a $600 market price in a short period of time, then they have serious problems.

So I set my buffer to 0.1% and max limit at 10 cents. That would mean anything over $100 symbol value would have a 10 cent buffer. That’s more than reasonable enough.

[ScottMcNab]

Matthew O’Keefe wrote:

Something like previous close at 10, limit set for 8.65, backtester will only pass a successful fill through to the trade list if Low of the day hits 8.50, yet it passes the trade through to the trade list at a fill of 8.65, not at a fill of 8.50. If the low of the day only gets to say, 8.58, then it assumes you did not get the fill and trade would not make it through to the trade list.

Hi Matthew…would this work (without having to touch the CBT code)

Tick = iif(inwatchlistname(“IB five cents”),0.05,0.01);
BuyLimVal = round(BuyLimP/Tick);
BuyLimit2 = (BuyLimVal * Tick);
buylimit = buylimit2 – tick; //(or 3*tick etc)

LE = Ref(BuySetup,-1) ;
LEPrice = Min(Open,Ref(BuyLimit2,-1));

Apologies if it’s rubbish and wasted your time

[JulianCohen]

Using that code addition Matthew, my results went from 31% CAGR and -15% MDD to 8% and -22% MDD

I will keep trading the two R2000 systems for a while and monitor closely. Could be back to R 1000 only soon.

[Anonymous]

What settings did you use? And how many trades were “dropped” compared to the original backtest?

For me, I had 8,000 trades, but after the code and with 0.1% buffer and 10 cent limit I dropped to 7,350 trades. Interestingly, the winning trades were 4,434 down to 3,810 and the losing trades from 3,565 down to 3,532. So it is very interesting to see that with just a few cents buffer, and no more than 10 cents buffer on the larger symbols, I lost 14% of my winning trades (down 624) and lost less than 1% of the losing trades (down just 33 trades). You could therefore probably deduce that our thinking was correct, that it is the wins that are tightly within cents of the daily low where some profit does lie, and losing these is having an effect on our real time results compared to backtest.

Is it realistic to think that from backtesting to real trade we would lose 14 % of the winning trades? Probably a bit steep. At 0.05% buffer I lost 8% (353) of winners and just 0.3 of a percent (13) of losers.

As long as we have a mechanism to allocate something of a factor to lost trades, we can then still build systems, get them to where we think we are happy to trade them, then throw this little bit of code at it to see what the “worst case” scenario might look like. If systems look great, then engage this code and they are still acceptable and tradeable, perhaps that is another good measure for robustness. If however you engage the code and it totally falls over, maybe that is telling you something.

I thought it might be good to be able to see/calculate how close the fill prices are to the Low of the day. Therefore I fiddled with custom backtester a little more……

// Put this in just before the SetCustomBacktestProc(“”); line

StaticVarSet(Ticker + “LOW”, L );

// Then put this in after the } // End of for loop over bars but before the bo.PostProcess();

for ( trade = bo.GetFirstTrade( ); trade; trade = bo.GetNextTrade( ) )
{
symbolLOW = StaticVarGet( trade.Symbol + “LOW” );
trade.AddCustomMetric( “Daily Low”, Lookup( symbolLOW, trade.EntryDateTime ) );
}
bo.ListTrades();

This code will then add an extra column to your backtest trade list for the low price of the day. You can then copy and paste trade list to Excel and have a further look at how many trades are close to the low price of the day. Filter them, do further calcs etc. I found it quite interesting that before the buffer code I had 270 trades out of 8000 that were exactly the same limit price as the Low price of the day. Stretching that out to within 1 cent it is 337 trades and to within 2 cents was just over 400 trades.

So going back to the buffer settings, perhaps something more like 0.05% buffer with 10 cent max to knock out the “on the margin” trades is probably a nice balance between getting rid of the trades we know are going to fail first, and still defending reasonable results. And remember, this is only a mechanism to temper our enthusiasm in real time trade vs backtested results. If we get very aggressive with ourselves on this settings and start being happy with more conservative backtest results, but then much more favourable real time results present themselves, that is not necessarily a bad thing. It might actually cheer us grumpy pricks up for once. Hoping for 20’s and getting 25’s is certainly better than hoping for 25’s and getting 20’s.

[JulianCohen]

Four out of five MOCs were operational last night. STT is now struggling to upload 494 trades. Luckily I set up a data dump with a pivot table so I know exactly what my P/L is. The MOCs made money last night which offset losses everywhere else.

I also changed to tiered brokerage as I am trading more than 1m units of shares per month due to the volume of the MOCs (Four of them are running at 80 positions at 5%). The bro last night averaged out at .004.

[Nick Radge]

Good night for my MOC’s as well and cements my thoughts on increasing exposure to these and decrease away from trend systems.

Still 70% trend and 30% MR.

[TimothyStrickland]

I don’t have a MOC yet, still need to make one but my MRV faired pretty well during the drop, my momentum system took a big hit. I need to get to work on my MOC!

[JulianCohen]

Today (last night) my MOCs copped it big time. Near enough took away all January’s gains. However they are also quick to respond to losses, in backtesting at least, so watch this space….

[Nick Radge]

My combo MOC is -1.55% for the month and +3.7% YTD.

Remember that volatility clusters at these times and large swings in both directions occur.

[JulianCohen]

Oh yes. I’m trying not to have expectations but generally a big MOC loss is followed by a big gain.

[JulianCohen]

February ’20

Combined US MOC: -8.6 %

Long Term Systems

S&P 500 Momentum: -7.83%
NASDAQ Momentum: -6.31%
Long Term NASDAQ: -6.84%

ASX Growth -8.46%

Total Account: -9.35%

[Author]

Posts