How to best represent partial trade liquidation in backtest reports

[fan27]

I have written my own backtesting engine and am currently working on a feature where a portion of a lower ranked strategy's position can be liquidated in favor of a higher ranked strategy position. In my reporting, let's say I have trade:

ticker qty entry date entry price exit date exit price
xyz 100 2/3/2015 105 open

What would make the most sense to see if I liquidated half of the position now and the other half later.

One option, create an additional trade entry with half the quantity and update the original:

ticker qty entry date entry price exit date exit price
xyz 50 2/3/2015 105 6/15/2015 110
xyz 50 2/3/2015 105 open

Is there another (more standard) way in commercial backtesting software this would be represented?

thanks
fan27

 

[rb7]

This is the way I do:
Because it's the same position, the closing trade prices are averaged, keeping only one line per position in the report. The exit date/time is the time stamp of the last trade.

Ex.:
Open trade: 100@2010.50 (on Thu)
Closing trades: 50@2011.75 (on Thu) + 50@2012.25 (on Fri) = 100@2012.00 (on Fri)
P/L =2012.00 - 2010.50 = 1.50 (for a Long position)

Then, on the report, I'd see this:
Qty, EntryPrice, EntryDate, ExitPrice, ExitDate, P/L
100, 2010.50, 20150723, 2012.00, 20150724, +1.50

I don't know how commercial software handle this.

r.

 

[fan27]

This is the way I do:
Because it's the same position, the closing trade prices are averaged, keeping only one line per position in the report. The exit date/time is the time stamp of the last trade.

Ex.:
Open trade: 100@2010.50 (on Thu)
Closing trades: 50@2011.75 (on Thu) + 50@2012.25 (on Fri) = 100@2012.00 (on Fri)
P/L =2012.00 - 2010.50 = 1.50 (for a Long position)

Then, on the report, I'd see this:
Qty, EntryPrice, EntryDate, ExitPrice, ExitDate, P/L
100, 2010.50, 20150723, 2012.00, 20150724, +1.50

I don't know how commercial software handle this.

r.

Thanks rb7. My concern with that representation is I will likely need more columns in my already crowded data table. Plus, I currently key off of exit date when calculating performance metrics over time so having multiple exit dates in one line item would make that code more complicated. That being said, your representation is very human readable. I will give it some thought.

thanks
fan27

 

[i960]

Thanks rb7. My concern with that representation is I will likely need more columns in my already crowded data table. Plus, I currently key off of exit date when calculating performance metrics over time so having multiple exit dates in one line item would make that code more complicated. That being said, your representation is very human readable. I will give it some thought.

thanks
fan27

How would there be multiple exit dates for the same line item? Surely you're giving each *trade* its own row. I don't see how you have to track anything additional here. Positions are based off of trades, they're not something you store and modify - although if you have 1000s of them you can do that for efficiency reasons, but it's still separate from component trades. What I'm saying is that a position is the *result* of a bunch of trades and you use math to calculate/aggregate it.

 

[fan27]

How would there be multiple exit dates for the same line item? Surely you're giving each *trade* its own row. I don't see how you have to track anything additional here. Positions are based off of trades, they're not something you store and modify - although if you have 1000s of them you can do that for efficiency reasons, but it's still separate from component trades. What I'm saying is that a position is the *result* of a bunch of trades and you use math to calculate/aggregate it.

Good points. It is convenient though to have both the entry and exit on the same line, at least when the position is fully liquidated via one trade.

thanks
fan27

 

[i960]

Good points. It is convenient though to have both the entry and exit on the same line, at least when the position is fully liquidated via one trade.

Well you're totally free to do that, I just meant store the trades per row and represent the position as a calculation based on the trades. Maybe I'm missing something here and you're just talking about a spreadsheet or something. I figured you were talking database. Either way - the position is a dynamic representation at all times until closed (at which point exit columns become valid) based on underlying trades.

 

[fan27]

Attached is how I am currently representing positions (stop/limit orders currently not showing up as expected). As you can see there is already a lot of data here.