Limit position size with Futures symbols

mschneider

#1

11/7/2012 12:01 PM

Hi,

I need a way to limit Position Sizes in Future Mode. The main setup should be let's say 'Starting Capital = 10000' and 'MaxPercentRisk = 10%'.
Now in real world trading (mini...) it's not realistic to trade 1000000000 contracts so that I would like to limit each trade to max 10000 contracts.
I tried 'Position Options' from the PositionSizer Library: 'Max Invested $' doesn't seem to work in Future Mode (= no trades at all), 'Adjust size to XX$' seems to be ignored in Future Mode.
Another approach I tried was to write an own PositionSizer based on the demo. This one seems to work but while a 'standard' strategy execution takes 0.8 seconds to execute my demo based PosSizer takes 10 seconds and more which is (in my case) useless for backtesting.

Is there something I might have missed...?

Eugene

#2

11/7/2012 1:20 PM

Hi Michael,

QUOTE:
Another approach I tried was to write an own PositionSizer based on the demo. This one seems to work but while a 'standard' strategy execution takes 0.8 seconds to execute my demo based PosSizer takes 10 seconds and more which is (in my case) useless for backtesting.

You overlooked a bottleneck in the custom PosSizer code. PosSizers don't come with a speed penalty.

QUOTE:
I tried 'Position Options' from the PositionSizer Library: 'Max Invested $' doesn't seem to work in Future Mode (= no trades at all), 'Adjust size to XX$' seems to be ignored in Future Mode.

That's right: basis price is not honored. I can fix it in next build of MS123 PosSizers, if you could help me by reviewing and correcting the proposed changes to the formulas (in bold):

1. 'Max Invested $'

To work with Futures symbols, the existing (position size x Basis Price) value should be multiplied by the Point Value, right?

Also, should the current position size be multiplied by the Point Value?

2. 'Adjust size to XX$'

If (Current Size x Basis Price x Point Value) < Minimum Required Order Size

then adjust the size as follows:

Minimum Allowed Order Size / Basis Price x Point Value

--

I appreciate if this can be verified.

mschneider

#3

11/8/2012 12:52 PM

Hi Eugene,

Sorry, I dont get it I think...:

QUOTE:

You overlooked a bottleneck in the custom PosSizer code. PosSizers don't come with a speed penalty.

Is there something I can do myself or is this by design?

I really would appreciate to help you but my Testing-Symbol's FutureMode Setup is
-
Margin: 2
Point Value 0.01
Tick 1
Decimals: 0
-
so that (Basis Price independent) the Cash/Equity is only be divided by the Margin to get the Position Size. In 'my' PositionSizer the limit is simply limited by

CODE:
Please log in to see this code.

Eugene

#4

11/8/2012 1:00 PM

There's nothing wrong with this code that could slow the processing down from <1s to 10s. It's something else. Consider using a debugger/profiler to find out the bottleneck:

Is there a way to profile Wealth-Lab 6 Strategies i.e. measure application/script performance?

mschneider

#5

11/9/2012 3:30 PM

I must admit before WealthLab I didnt know anything about C# or coding at all. Eugene, I'm sure it is something else, I also tried to figure it out by comparing a 'standard WL Position Sizer (10% Risk)' to the one I took from the 'Create a PosSizer.pdf'. It's obvious that there is something wrong since it consumes 10x more workload. But to understand the profiler output I seem to either need more knowledge about .Net or WealthLab under the hood.
I only could drill down processing to find a bottleneck at 'ApplyPositionSize -> BuildEquityCurve -> ?'.

http://img72.imageshack.us/img72/4403/profiler.jpg

CODE:
Please log in to see this code.

Size:

Color:

I must admit before WealthLab I didnt know anything about C# or coding at all. Eugene, I'm sure it is something else, I also tried to figure it out by comparing a 'standard WL Position Sizer (10% Risk)' to the one I took from the 'Create a PosSizer.pdf'. It's obvious that there is something wrong since it consumes 10x more workload. But to understand the profiler output I seem to either need more knowledge about .Net or WealthLab under the hood.
I only could drill down processing to find a bottleneck at 'ApplyPositionSize -> BuildEquityCurve -> ?'.

[LINK]http://img72.imageshack.us/img72/4403/profiler.jpg[/LINK]

[CODE]using Fidelity.Components;
using System.Windows.Forms;

namespace WealthLab.PosSizers
{
    public class MaxPositionSize : BasicPosSizer, ICustomSettings
    {
        public override double SizePosition(Position currentPos, Bars bars, int bar, double basisPrice, PositionType pt, double riskStopLevel, double equity, double cash)
        {
            double size = CalcBasicPositionSize(bars, bar, pt, basisPrice, riskStopLevel, equity);

if (size > _maxSize)
                size = _maxSize;

return size;
        }

public override string FriendlyName
        {
            get
            {
                return "max 10.000 contracts";
            }
        }

private int _maxSize = 10000;
        private MaxPositionSizeSettings _settings = null;

public UserControl GetSettingsUI()
        {
            if (_settings == null)
                _settings = new MaxPositionSizeSettings();
            _settings.MaxSize = _maxSize;
            InitializeSettings(_settings);
            return _settings;
        }

public void ChangeSettings(UserControl ui)
        {
            _maxSize = _settings.MaxSize;
            ChangeBasicSettings(_settings);
        }

public void ReadSettings(ISettingsHost host)
        {
            _maxSize = host.Get("MaxPositionSize.MaxSize", 10000);
            ReadBasicSettings(host);
        }

public void WriteSettings(ISettingsHost host)
        {
            host.Set("MaxPositionSize.MaxSize", _maxSize);
            WriteBasicSettings(host);
        }
        
    }

public class MaxPositionSizeSettings : PosSizerSettingsBase
    {
        public int MaxSize { get; set; }

protected override void Dispose(bool disposing)
        {
            base.Dispose(disposing);
        }

}
}[/CODE]

Eugene

#6

11/9/2012 4:06 PM

1. Make sure you're running the release build (as opposed to debug build).
2. Also, running under debugger may slow down an assembly's performance.

mschneider

#7

11/12/2012 10:21 AM

The 1sec / 10sec difference unfortunately appears in the release version...
I tried to find out more with different profiler tools but they all pointed to WealthLab.Position.get_entryBar() and a possible thread synchronization bottleneck:

http://img818.imageshack.us/img818/5161/pofile2.jpg

Eugene

#8

11/12/2012 11:09 AM

Please disregard my advice on experementing with the profiler, I haven't seen your code at that point which on the surface appears OK (haven't compiled it though). Try downloading the sample project's source code from the Home - MS123.PosSizers page (attachment): it's a watered down version of the library that works.

It may take time to find out what's wrong with your setup, because it's not becoming evident from the information already available. If there's a "synchronization bottleneck", then it certainly can't be caused by applying a PosSizer. Either you're comparing the built-in PosSizer running on 500 bars (or 1 symbol) with custom PosSizer running on 10,000 bars (or 1000 symbols), or there's something else to it in your workflow not apparent from your posts.

So I'd appreciate if you could take a look at questions in my reply dated 11/7/2012 1:20 PM. Fixing the working solution may be a shortcut. Thanks.

mschneider

#9

11/12/2012 1:09 PM

I think I forgot to mention that I've already tried to fix this with the OpenSource MS123.PosSizer. Just to proof it for this reply
a) I did a clean WealthLab install
b) I downloaded the PosSizer source code and changed the necesarry values 'TargetFramework 2.0 -> 4.0' and the Folder 'WL v5 -> WL v6', compiled a release version.
c) Run a simple 'SMA in/out' strategy with the build-in '10% Max Risk' PosSizer, then with the 'Random non-basic' PosSizer.

I always get the same result: Build-In PosSizer takes something between 750 and 1250 ms, the 'external one' 9000 - 11000ms. My intention was to use the included MS123.PosSizer to check if it's up to my code...

Eugene

#10

11/12/2012 1:49 PM

It's not the code, it's something specific to your system and/or the way the DLLs are compiled.

1. Does MS123 PosSizers work equally fast (on par with the built-in PosSizers)?
2. Which version of Visual Studio are you using to compile your DLLs?
3. How are you starting Wealth-Lab, by clicking on its shortcut or from Visual Studio?
4. Does the Wealth-Lab's main folder contain any other custom DLLs (i.e. developed by you or 3rd party and not downloaded from the Extensions section of our site)?

mschneider

#11

11/12/2012 2:38 PM

1) That's what I tried, the build-in PosSizers run a strategy in 850ms, a MS123PosSizer (any of them already included) take 9-11 seconds.
2) VisualStudio 2012 without any extensions
3) I'm starting WealthLab with it's shortcut
4) There are some DLL's installed by the following extensions:
- ASCII Files Static (which I dont need but without I couldnt get DatabaseProvider to work)
- Database Provider
- Yahoo

Eugene

#12

11/12/2012 3:00 PM

Did I understand correctly: you have ran a backtest with "Percent of Equity", and then applied a MS123 PosSizer or your own PosSizer, and this step takes 11 seconds?

For the record, what kind of data are these 850ms coming from? Data provider, data loading range, whatever else you feel is applicable.

mschneider

#13

11/12/2012 3:04 PM

Another DLL which I compiled and normally use with the same setup is the Community.Commissions without any problems. At the moment this DLL is abandoned to maintain a clean installation...

mschneider

#14

11/12/2012 3:24 PM

My WealthLab Testing Setup:

BarScale: 1minute
DataRange: about 6 months
Bars: 107660
DataProvider: Static SQL DB

Position Sizers with their Execution Times
Portfolio Sim Mode
Starting Capital: 10000
-
Fixed Dollar: 1000€ -> 839ms
Shares/Contracts: 1000 -> 740ms
Percent of Equity: 10 -> 844ms
Max Percent Risk: 10 -> 836ms
-
Double Down /w MaxRisk 10%: -> 12308ms
Double Down /w PercentEquity 10%: -> 18014ms
Double Down /w Shares/Contracts 1000: -> 13728ms
-
Random PosSizer /w MaxRisk 10%: -> 13395ms
Random PosSizer /w PercentEquity 10%: -> 18461ms
Random PosSizer /w Shares/Contracts 1000: -> 15814ms

- the Symbol is running in Future Mode
- no Commission are applied (as described above)
- Performance Visualizer activated are 'Performance' and 'Trades'
- If I run the 'Double Down' PosSizer without 'my' DLL in the WL Folder the results are as bad as above.

- Strategy Code:

CODE:
Please log in to see this code.

Size:

Color:

My WealthLab Testing Setup:

BarScale: 1minute
DataRange: about 6 months
Bars: 107660
DataProvider: Static SQL DB

[b]Position Sizers with their Execution Times[/b]
Portfolio Sim Mode
Starting Capital: 10000
-
Fixed Dollar: 1000€ -> 839ms
Shares/Contracts: 1000 -> 740ms
Percent of Equity: 10 -> 844ms
Max Percent Risk: 10 -> 836ms
-
Double Down /w MaxRisk 10%: -> 12308ms
Double Down /w PercentEquity 10%: -> 18014ms
Double Down /w Shares/Contracts 1000: -> 13728ms
-
Random PosSizer /w MaxRisk 10%: -> 13395ms
Random PosSizer /w PercentEquity 10%: -> 18461ms
Random PosSizer /w Shares/Contracts 1000: -> 15814ms

- the Symbol is running in Future Mode
- no Commission are applied (as described above)
- Performance Visualizer activated are 'Performance' and 'Trades'
- If I run the 'Double Down' PosSizer without 'my' DLL in the WL Folder the results are as bad as above.

- Strategy Code:
[CODE]
using System;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;

namespace WealthLab.Strategies
{
	public class PerformanceTest : WealthScript
	{
		private StrategyParameter _longPer;
		private StrategyParameter _shortPer;
		
		public PerformanceTest()
		{
			_longPer = CreateParameter("longPer",20,10,50,10);
			_shortPer = CreateParameter("shortPer",5,1,10,1);
		}		
		protected override void Execute()
		{
			DataSeries ma_long = EMA.Series(Close, _shortPer.ValueInt, EMACalculation.Modern);
			DataSeries ma_short = EMA.Series(Close, _longPer.ValueInt, EMACalculation.Modern);
			PlotSeries(PricePane,ma_long,Color.Green,LineStyle.Solid,2);
			PlotSeries(PricePane,ma_short,Color.Red,LineStyle.Solid,2);
			
			for(int bar = _longPer.ValueInt + 1; bar < Bars.Count; bar++)
			{
				if (IsLastPositionActive)
				{
					ExitAtStop(bar+1,LastPosition,LastPosition.RiskStopLevel,"RiskStopLevel");
					
					if(ma_short[bar] > ma_long[bar])
						SellAtMarket(bar+1,LastPosition,"BuyLong");
					if(ma_long[bar] > ma_short[bar])
						CoverAtMarket(bar+1,LastPosition,"BuyShort");
				}
				else
				{
					if(ma_long[bar] > ma_short[bar])
					{
						RiskStopLevel = Low[bar] - 10;
						BuyAtMarket(bar+1,"BuyLong");
					}
					if(ma_short[bar] > ma_long[bar])
					{
						RiskStopLevel = High[bar] + 10;
						ShortAtMarket(bar+1,"BuyShort");
					}
				}
			}
		}
	}
}
[/CODE]

Eugene

#15

11/12/2012 4:12 PM

Well, usually I do not run tests on hundreds of thousands bars. Indeed, here applying a PosSizer is slower than any of the built-in options (e.g. 2 vs 4 seconds or 7 vs 9 seconds). I think that having an overhead is expected.

mschneider

#16

11/12/2012 4:26 PM

Even if I take half of these bars the difference is still 0.5seconds vs. 5.5 seconds. But if there's nothing wrong about this behaviour or the code or at least nothing I can improve then I'll take it as given.

Thank You Eugene.

Eugene

#17

11/12/2012 4:31 PM

Maybe something could be done by using parallel programming in custom PosSizers (i.e. Parallel.For and/or PLINQ). Of course, when there's room for that -- alas, not in your MaxPositionSize class.

Eugene

#18

11/13/2012 12:56 AM

Matthias,

A couple more observations:

1. I noticed that 64-bit version appears faster on processing PosSizers than 32-bit version e.g. by 20% on Double Down.
2. 6.3 vs. 6.4 i.e. .NET 2.0/3.5 vs. .NET 4.0 - doesn't make difference wrt Double Down performance.