Position Priority: LimitPriorityLong, SetTimeOfDayPriority, IntradayFillPriorityEstimate

avishn

#1

12/16/2009 9:36 PM

I have a daily strategy with high exposure (high/spiking number of entry signals). Limit entry orders. It is my understanding that there are three options to test it in portfolio mode -

* Random position priority (default)... Does not give repeatable results (duh!)
* "Priority=Close[bar]" seen in many code samples on this forum... Makes results repeatable but less realistic (gives preference to higher priced stocks)
* Worst case scenario portfolio setting... Unrealistic (I know, I know), though useful as a reality check, but NOT for strategy comparison/fine tuning.

I'm trying to estimate which limit orders will realistically be hit first. Without dropping to the intraday data level, which brings a whole new set of performance and data size limit issues, I've came up with the following --

If we assume that the closer the limit price to the open, the more likely it is to be hit, we can set the priority to

(reverse of distance, smaller distance gives higher priority). This needs to be normalized to volatility somewhat, so the final formula looks like this:

I'm wondering if anybody else experimented with something like that and if results can be considered more or less reliable for sufficiently large values of X (bars, stocks). Is there possibly a better approach?

EDIT: I do realize that this is peeking. I think it should be fine, since it is used only to make testing results more realistic.

EDIT2 (12/27/09): Much more accurate estimate can be achieved for long limit entries with

... where p is limit price. This gives quick and dirty approximation (compare to the results of the 100% accurate TimeOfDay method below which requires intraday data). Useful when scanning large data sets.

EDIT3 (3/8/2010): See updated version below in the post from 3/8/2010 (IntradayFillPriorityEstimate)

Size:

Color:

I have a daily strategy with high exposure (high/spiking number of entry signals). Limit entry orders. It is my understanding that there are three options to test it in portfolio mode -

* Random position priority (default)... Does not give repeatable results (duh!)
* "Priority=Close[bar]" seen in many code samples on this forum... Makes results repeatable but less realistic (gives preference to higher priced stocks)
* Worst case scenario portfolio setting... Unrealistic (I know, I know), though useful as a reality check, but NOT for strategy comparison/fine tuning.

I'm trying to estimate which limit orders will realistically be hit first. Without dropping to the intraday data level, which brings a whole new set of performance and data size limit issues, I've came up with the following --

If we assume that the closer the limit price to the open, the more likely it is to be hit, we can set the priority to [CODE]1 / Math.Abs(Open[bar+1] - limitPrice)[/CODE] (reverse of distance, smaller distance gives higher priority). This needs to be normalized to volatility somewhat, so the final formula looks like this: [CODE]LastActivePosition.Priority = (High[bar+1] - Low[bar+1])/ Math.Abs(Open[bar+1] - limitPrice);[/CODE]

I'm wondering if anybody else experimented with something like that and if results can be considered more or less reliable for sufficiently large values of X (bars, stocks). Is there possibly a better approach?

EDIT: I do realize that this is peeking. I think it should be fine, since it is used only to make testing results more realistic.

EDIT2 (12/27/09): Much more accurate estimate can be achieved for long limit entries with 
[CODE]        double LimitPriorityLong(double p, int bar) {
            double o = Open[bar]; double h = High[bar]; double l = Low[bar]; double c = Close[bar]; double v = Volume[bar];
            if (p > o) {
                return -v/1000000;                  // gap down below limit price, return small negative (deterministic)
            } else {
                if (c > o) {
                    return (o-p) / (h-l);           // assuming short travel down to limit price before going up
                } else {
                    return (2*h-(o+p)) / (2*(h-l)); // assuming travel up first and then down to limit price
                }
            }
        }[/CODE]
... where p is limit price. This gives quick and dirty approximation (compare to the results of the 100% accurate TimeOfDay method below which requires intraday data). Useful when scanning large data sets.

EDIT3 (3/8/2010): See updated version below in the post from 3/8/2010 (IntradayFillPriorityEstimate)

Cone

#2

12/17/2009 7:23 AM

The right way to do it for Limit entry orders is by assigning the Position Priority using time of day. In Version 4, we had the TIntraDay study that provided that ability. Unless Eugene has already done it, we need to work on this for v5. Your poor-man's guesstimate is probably sufficient for the task though.

But look, this is fine just to see "what could have been", but it's just a single simulation that will never repeat in the same order again. Random is the right way go if you're evaluating your Strategy, and to that end, you should be looking at the Monte Carlo Visualizer, new for 5.6.

avishn

#3

12/17/2009 8:49 AM

Thank you.

It appears that TIntraDay tool is exactly what I would need. Also it seems it would help with the "limit exit at profit target unless stop loss is hit on the same bar" scenarios, which usually are very difficult to analyze through backtesting on daily data.

I'm curious what are the mechanics behind TIntraDay study in WL4? I guess it requires presence of intraday data for the same symbol. Anyways it would probably be different in WL5...

Yes, I'm looking into Monte-Carlo randomization now. I understand that to get closer to the true mean and variance of the returns I will need to randomize and resample the data. For me "what could have been" approach is interesting from the initial trade signal screening perspective to filter out signals and parameters which would definitely not work.

Eugene

#4

12/17/2009 9:03 AM

For sure. Intraday datasource is required.

btw, another approach and some V4 code to help with the "what hit first" scenarios:

Bouncing Tick & Ordering of Fills

avishn

#5

12/22/2009 4:53 PM

I guess I need to bring this issue up again.

Let's take BasicHiLoLimit strategy by DrKoch, or any other strategy which generates high number of limit entry orders for almost every bar. Testing it as is, without the position priority set, gives grossly incorrect (too optimistic) results. The reason being is that with the limit buy order, when the stock gaps down, we're guaranteed to get an execution at the open, which in most cases would be very unfavorable for that kind of a strategy (bottom fishing).

Let's say we have 20% equity position sizing, 1,000 signals for the given bar and 50 of those stocks gap down. In real life we're guaranteed to get 100% of our 100%/20%=5 maximum available executions from that pool of 50 gaped down stocks. However, without the priority set, the chances to enter one of those unfavorable trades are being reduced by WL to only 50/1,000=0.5%. More than that, the same problem persists even when using MonteCarlo trade randomizer, because, again, the trades will be selected randomly from the pool of 1,000 trade signals without any respect to what could've/should've happened if trade signals from that pool of 1,000 were executed in real life for sufficiently high number of trade sequences.

I understand that the problem have been discussed before, but I don't think there's any reliable solution available at the moment. I'm not sure how the prevously mentioned TIntraDay works in terms of all memory and I/O overhead and if we can get that solution available any time soon...

I was thinking that one way to fix it without switching to intraday data would be to generate and store some additional information along with each daily bar. Essentially what we need is a sequence of new alternating highs and lows for every day with timestamps, something like
09:30 LOW 15.10
11:30 HIGH 16.75
14:00 LOW 15.05
...in addition to your standard OHLC and Volume. In most cases there would be just a handful of additional data points for each bar.

The problem is that kind of data is not available from Fidelity, and even though the algorithm to extract it is very simple, I'm not sure how to generate it on the fly when needed (or when downloading the data update). Again the idea being that we don't want to suck all of the intraday data into memory when backtesting just to answer the question which stock dropped to the limit price first.

EDIT: This is what a yearly profit probability chart looks like for the slightly modified (single position per symbol) HiLoLimit strategy:

Chance of break even is 98.90%... Sign me up!

At the same time, an informal estimate of unfavorable trades outside of MonteCarlo tool gives the chance of break even somewhere below 50%.

Size:

Color:

I guess I need to bring this issue up again.

Let's take BasicHiLoLimit strategy by DrKoch, or any other strategy which generates high number of limit entry orders for almost every bar. Testing it as is, without the position priority set, gives grossly incorrect (too optimistic) results. The reason being is that with the limit buy order, when the stock gaps down, we're guaranteed to get an execution at the open, which in most cases would be very unfavorable for that kind of a strategy (bottom fishing).

Let's say we have 20% equity position sizing, 1,000 signals for the given bar and 50 of those stocks gap down. In real life we're guaranteed to get 100% of our 100%/20%=5 maximum available executions from that pool of 50 gaped down stocks. However, without the priority set, the chances to enter one of those unfavorable trades are being reduced by WL to only 50/1,000=0.5%. More than that, the same problem persists [b]even when using MonteCarlo trade randomizer[/b], because, again, the trades will be selected randomly from the pool of 1,000 trade signals without any respect to what could've/should've happened [i]if trade signals from that pool of 1,000 were executed in real life for sufficiently high number of trade sequences[/i].

I understand that the problem have been discussed before, but I don't think there's any reliable solution available at the moment. I'm not sure how the prevously mentioned TIntraDay works in terms of all memory and I/O overhead and if we can get that solution available any time soon...

I was thinking that one way to fix it without switching to intraday data would be to generate and store some additional information along with each daily bar. Essentially what we need is a sequence of new [i]alternating[/i] highs and lows for every day with timestamps, something like 
09:30 LOW 15.10
11:30 HIGH 16.75
14:00 LOW 15.05
...in addition to your standard OHLC and Volume. In most cases there would be just a handful of additional data points for each bar.

The problem is that kind of data is not available from Fidelity, and even though the algorithm to extract it is very simple, I'm not sure how to generate it on the fly when needed (or when downloading the data update). Again the idea being that we don't want to suck all of the intraday data into memory when backtesting just to answer the question which stock dropped to the limit price first.

EDIT: This is what a yearly profit probability chart looks like for the slightly modified (single position per symbol) HiLoLimit strategy:
[IMG]http://img15.imageshack.us/img15/1885/inflatedprofit.jpg[/IMG]

Chance of break even is 98.90%... Sign me up!

At the same time, an informal estimate of unfavorable trades outside of MonteCarlo tool gives the chance of break even somewhere below 50%.

Cone

#6

12/22/2009 5:08 PM

Sure it is, back to April 2004. You can create these data from 30-min intraday bars.

But if you want accuracy, the TIntraday-type solution is the way to go. It doesn't make sense to me to put effort anywhere else.

avishn

#7

12/22/2009 5:50 PM

Is there any ETA on the solution you're describing? If not, I guess I can write something for the time being and share it here... Hopefully with some more or less intelligent caching. The only question is how do I access intraday data for the current symbol from daily strategy in WL5?

Cone

#8

12/22/2009 6:07 PM

ETA: a few minutes. I think this will be really easy in v5.

Cone

#9

12/22/2009 7:01 PM

Well, there's always something that hangs you up when you get started on something new.. no exception this time. But here you go, with an example. Be sure to read the comments for the TimeAtPrice function.

Size:

Color:

Well, there's always something that hangs you up when you get started on something new.. no exception this time.  But here you go, with an example.  Be sure to read the comments for the TimeAtPrice function. 
[CODE]using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;

namespace WealthLab.Strategies
{
	public class LimitPriorityTest : WealthScript
	{		
		/* Assumes BuyAtLimit or SellAtStop only, 0 Slippage
		   The function returns the first time of day (HHmm) at which the Low crossed the price.
		   Negate the result so that the earlier times are higher priority,
		   Update your intraday DataSet(s) before running, or turn off On-demand data.
		*/
		public int TimeAtPrice(string intradayDataSet, string symbol, DateTime dt, double price)
		{
			bool inRange = false;
			int barsToday = 0;
			
			// Grab the intraday data from specified dataSource
			Bars intra = GetExternalSymbol(intradayDataSet, symbol, false);
						
			// Find the first bar with dt (if exists)
			int bar = intra.Count - 1;			
			bar -= intra.IntradayBarNumber(bar);
			do
			{					
				if (intra.Date[bar] <= dt )
				{
					inRange = true;
					bar += (barsToday + 1);
					break;
				}
				else 
				{		
					bar--;
					barsToday = intra.IntradayBarNumber(bar);
					bar -= barsToday;
				}
			} while (bar > 0);
			
			if (!inRange) 
				return 2500;
			
			// Find the bar, if exists
			for (int n = bar; n <= bar + barsToday; n++)
			{
				if ( intra.Low[n] <= price )
					return intra.Date[n].Hour * 100 + intra.Date[n].Minute;
			}
			return 2400;		// in range, but price didn't cross			
		}
		
		protected override void Execute()
		{	
			double priority = 0d;
			for(int bar = 20; bar < Bars.Count; bar++)
			{
				if (IsLastPositionActive)
				{
					Position p = LastPosition;
					if (bar - p.EntryBar > 2) SellAtMarket(bar + 1, p);
				}
				else
				{
					double limitPrice = 0.96 * Close[bar];
					if (bar < Bars.Count - 1 )
						priority = TimeAtPrice("Dow 30_1", Bars.Symbol, Date[bar + 1], limitPrice);
					Position p = BuyAtLimit(bar + 1, limitPrice, priority.ToString());
					if (p != null) p.Priority = -1 * priority;
				}
			}
		}
	}
}[/CODE]

avishn

#10

12/22/2009 7:46 PM

Awesome! Much appreciated.

Cone

#11

12/23/2009 1:28 AM

Consider that a proof of concept. There's a better way to get this done in a single procedure call at the end of the script.

Cone

#12

12/23/2009 5:37 PM

Here's another shot at a more robust method. Once it's vetted, maybe we can get Eugene to massage it into the 2010.1 Community.Components update. Then it's just a matter of calling the SetTimeOfDayPriority method after the trading loop.

A couple nice features of this version:
1. It can tell if you're missing a day of intraday data, and,
2. If a trade doesn't "cross" in the intraday data, the trade likely occurred due to a spike in the EOD bar. Here, this information is output to the debug window.

Finally, make sure to follow the guidelines in the comments.

Size:

Color:

Here's another shot at a more robust method.  Once it's vetted, maybe we can get Eugene to massage it into the 2010.1 Community.Components update.  Then it's just a matter of calling the SetTimeOfDayPriority method after the trading loop.

A couple nice features of this version:
1. It can tell if you're missing a day of intraday data, and,
2. If a trade doesn't "cross" in the intraday data, the trade likely occurred due to a spike in the EOD bar.  Here, this information is output to the debug window.

Finally, make sure to follow the guidelines in the comments.

[CODE]using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;

namespace WealthLab.Strategies
{
	public class LimitPriorityTestRevA : WealthScript
	{		
		/* 1. Automatically sets priority: Trades that occur earlier are assigned higher priority
		   2. Works for all stop/limit order typès
		   3. Assumes 0 Slippage
		   4. Update your intraday DataSet(s) before running, or, disable File > Update Data on Demand.
		   5. Recommended usage with intraday DataSet interval 5 minute or higher.
		
		   * Valid for scripts that trade 1-symbol only *
		*/
		
		public void SetTimeOfDayPriority(IList<Position> positions, string intradayDataSet)
		{		
			if (Positions.Count == 0) return;
			
			Position pos = Positions[0];
			string symbol = pos.Symbol;
			int lastIntraBar = 0;			
			Bars intra = GetExternalSymbol(intradayDataSet, symbol, false);

/* Valid only if first bar of intraday data is prior to the first trade */
			if (intra.Date[0] > pos.EntryDate)
			{
				throw new Exception("EOD data out of Intrday range for " + symbol);
				return;
			}
			
			int m = 0;
			foreach (Position p in positions)
			{	
				m++;
				if (p.Symbol != symbol)
				{
					throw new Exception("SetTimeOfDayPriority is invalid for multi-symbol scripts");
					return;
				}
				
				DateTime dt = p.EntryDate;
				bool checkLow = (p.PositionType == PositionType.Long && p.EntryOrderType == OrderType.Limit) ||
					(p.PositionType == PositionType.Short && p.EntryOrderType == OrderType.Stop);
				
				bool inRange = false;
				for (int bar = lastIntraBar; bar < intra.Count; bar++)
				{							
					if (intra.Date[bar] > dt)	// true = at first intraday bar of the day since EOD time is 00:00
					{
						if (intra.Date[bar].Day == dt.Day)
						{
							inRange = true;
							lastIntraBar = bar;		// Restart loop from here in case multiple Positions on same day
						}
						else
						{
							PrintDebug( "Intraday data missing for " + dt.ToShortDateString() );
							p.Priority = -2400;
						}
						break;
					}
				}
				
				if (inRange)
				{
					int n = lastIntraBar;
					do
					{
						if( checkLow )
						{
							if ( intra.Low[n] <= p.BasisPrice ) {								
								p.Priority = -1 * (intra.Date[n].Hour * 100 + intra.Date[n].Minute);	
								// PrintDebug(m + "\t" + p.Priority);
								break;
							}
						}
						else
						{
							if ( intra.Low[n] >= p.BasisPrice ) {								
								p.Priority = -1 * (intra.Date[n].Hour * 100 + intra.Date[n].Minute);								
								break;
							}
						}
						
						n++;
					} while (intra.Date[n].Day == dt.Date.Day && n < intra.Count);
										
					if (p.Priority > 0)		// false if trade cross checked
					{
						PrintDebug("Probable data spike, " + p.Symbol + " on " 
							+ p.EntryDate.ToLongDateString() + " at " + p.EntryPrice);
						p.Priority = -1e5;
					}
				}
				else
				{
					PrintDebug("Should not occur: intraday data insufficient for " + p.Symbol);
					p.Priority = -1 * 2400;
				}				
			}				
			intra.Cache.Clear();	// doesn't seem to help
		}
		
		/* Test usage in a dip buyer script */
		protected override void Execute()
		{	
			ClearDebug();
			for(int bar = 20; bar < Bars.Count; bar++)
			{
				if (IsLastPositionActive)
				{
					Position p = LastPosition;
					if (bar - p.EntryBar > 2) SellAtMarket(bar + 1, p);
				}
				else
				{
					double limitPrice = 0.96 * Close[bar];
					Position p = BuyAtLimit(bar + 1, limitPrice);
				}
			}
			
			/* Call the method after the trading loop */
			SetTimeOfDayPriority(Positions, "Dow 30_5");
			
			/* Check priority */			
			int j = 0;
			foreach (Position p in Positions)
			{
				j++;
				PrintDebug(j + "\t" + p.Priority + "\t" + p.EntryDate.ToShortDateString());
			}
		}		
	}
}[/CODE]

Eugene

#13

12/24/2009 2:22 AM

Great, will do.

Eugene

#14

1/3/2010 7:28 AM

Included. Thanks you guys for this helpful contribution.

avishn

#15

1/29/2010 12:19 PM

I'm seeing some strange behavior when using SetTimeOfDayPriority-instrumented strategy in optimization over a date range (this is important).

First of all, minimal code snippet to reproduce the problem (based on http://www2.wealth-lab.com/WL5WIKI/LimitOrderPriority.ashx) --

When I run the strategy it works fine and generates some trades. It works fine for "Most Recent 1 Year" as well as an arbitrary "Date Range" setting.

Now, in the beginning of the strategy I've added a parameter. It does not do anything, it just can take values of 0 and 1 (the specifics of the strategy parameter(s) are not important here). Now when I run optimization over "Most Recent 1 Year" I get back 2 optimization results (since the parameter can have 2 possible values) with some trades, nothing particularly interesting. But, when I do optimization over any "Date Range" (let's say 1/1/2008 to 1/1/2009), I get back no trades in any of the optimization results. It appears like the call to SetTimeOfDayPriority causes strategy to lose any position data. Why?

As a side note, I've double checked and I do have enough of 5 min historical data to support the selected date range.

EDIT: If I comment out this --

optimization starts working (i.e. generating trades) over any date range.

Size:

Color:

I'm seeing some strange behavior when using SetTimeOfDayPriority-instrumented strategy in optimization over a [i]date range[/i] (this is important).

First of all, minimal code snippet to reproduce the problem (based on [LINK]http://www2.wealth-lab.com/WL5WIKI/LimitOrderPriority.ashx[/LINK]) --

[CODE]using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;
using Community.Components;

namespace WealthLab.Strategies
{
	public class MyStrategy : WealthScript
	{
	
		StrategyParameter tParam;
		
		public MyStrategy() 
		{
			tParam = CreateParameter("Test", 0, 0, 1, 1); 
		}
		
		
		protected override void Execute()
		{
			PositionHelper ph = new PositionHelper( this );
			
			ClearDebug();
			for(int bar = 20; bar < Bars.Count; bar++)
			{
				if (IsLastPositionActive)
				{
					Position p = LastPosition;
					if (bar - p.EntryBar > 2) SellAtMarket(bar + 1, p);
				}
				else
				{
					double limitPrice = 0.96 * Close[bar];
					Position p = BuyAtLimit(bar + 1, limitPrice);
				}
			}
			
			/* Call the method after the trading loop */
			ph.SetTimeOfDayPriority(Positions, "Nasdaq 100 (5)");

}
	}
}
[/CODE]

When I run the strategy it works fine and generates some trades. It works fine for "Most Recent 1 Year" as well as an arbitrary "Date Range" setting.

Now, in the beginning of the strategy I've added a parameter. It does not do anything, it just can take values of 0 and 1 (the specifics of the strategy parameter(s) are not important here). Now when I run optimization over [i]"Most Recent 1 Year"[/i] I get back 2 optimization results (since the parameter can have 2 possible values) with some trades, nothing particularly interesting. But, when I do optimization over any [i]"Date Range"[/i] (let's say 1/1/2008 to 1/1/2009), I get back no trades in any of the optimization results. It appears like the call to SetTimeOfDayPriority causes strategy to lose any position data. Why?

As a side note, I've double checked and I do have enough of 5 min historical data to support the selected date range.

EDIT: If I comment out this --
[CODE]ph.SetTimeOfDayPriority(Positions, "Nasdaq 100 (5)");[/CODE]
optimization starts working (i.e. generating trades) over any date range.

Eugene

#16

1/30/2010 4:39 AM

Robert, could you take a look please?

I too have checked this setup in both WLP and WLD, different intraday providers, 30/60-min data to support priority, loaded a year of data starting from 1/1/2009 to 12/31/2009, had two optimization runs with the same numbers as when executing the strategy normally. In other words, I was unable to reproduce.

avishn

#17

2/15/2010 1:44 PM

In the SetTimeOfDayPriority source code above (from Community.Components), in the following section --

...shouldn't it be High, i.e.

in the second code branch?

(This is unrelated to the problem I've posted earlier on Jan 29)

Eugene

#18

2/17/2010 5:32 AM

The code was created by Robert, this week he's not around, so I'd suggest bumping it up later.

Cone

#19

2/20/2010 10:08 AM

Good catch avishn. The first if statement checks when the Low is at or below the basis price to trigger BuyAtLimit or ShortAtStop orders. Conversely, the second if statement should check if the High is at or above the basis price for ShortAtLimit or BuyAtStop orders.

Eugene, please make that correction for your next update. tia.

Eugene

#20

2/20/2010 10:16 AM

Done. Thanks Andrew.

avishn

#21

3/8/2010 9:11 AM

In case anybody is interested... Updated intraday fill priority estimate, now includes both long and short as well as limit and stop order support. Replaces the old LimitPriorityLong method from the first post in this thread.

How to use:

Eugene

#22

3/8/2010 9:39 AM

Thank you, will update Community.Components.

Eugene

#23

3/11/2015 5:15 PM

kribel asked:

I read the Setting Priority for AtStop/AtLimit Orders article.

I still have a few questions about this.

1) How does LimitPriorityLong() calculation work? Is it OpenSource? If yes, where can I get the code?
2) Is there a method LimitPriorityShort()?

Many Thanks!

07nioe asked:

Eugene

#24

3/11/2015 5:17 PM

Guys, I've moved your questions to the more suitable thread. Let's neither create new threads nor use an unrelated Strategy's thread and focus on LimitPriorityLong here where it has begun. Thanks.

kribel,

1) It's part of Community Components, an open source project.
2) No.

07nioe,

What's the problem with this approach?