Skip to content

Possible tradeStats() issue

3 messages · Michael Newell, OpenTrades, Brian G. Peterson

Original
Michael Newell
# 
I have recently come across an issue using the tradeStats() function
which was exposed by setting txnFees.  Looking at the tradeStats()
codes it attempts to determine the number of trades based on the
following logic:

PL.gt0 <- txn$Net.Txn.Realized.PL[txn$Net.Txn.Realized.PL > 0]
PL.lt0 <- txn$Net.Txn.Realized.PL[txn$Net.Txn.Realized.PL < 0]
PL.ne0 <- txn$Net.Txn.Realized.PL[txn$Net.Txn.Realized.PL != 0]
....
NumberOfTrades <- nrow(PL.ne0)

When not using txnFees your opening transaction of a trade have a PL
of 0 and hence this number does indeed match up with the number of
trades.  However as soon as you set a txnFees amount it means your
opening transaction has a PL equal to your txnFees (e.g. spread cost
of -0.0002).  This now doubles the "NumberOfTrades" as all opening
transactions have a PNL != 0 as shown below under PL column.

                    Txn.Qty Txn.Price Txn.Fees Txn.Value Txn.Avg.Cost
Net.Txn.Realized.PL
1990-01-01 00:00:00       0   0.00000    0e+00   0.00000      0.00000
           0.00000
2010-01-22 13:59:00       1   1.61112   -2e-04   1.61112      1.61112
          -0.00020
2010-01-25 15:59:00      -1   1.61837    0e+00  -1.61837      1.61837
           0.00725
2010-01-28 09:59:00      -1   1.62732   -2e-04  -1.62732      1.62732
          -0.00020
2010-01-28 16:59:00       1   1.61347    0e+00   1.61347      1.61347
           0.01385


There are a number of statistics in tradeStats() which use the PL.gt0,
PL.lt0 and PL.ne0 variables and therefore produce incorrect results
when txnFees>0.  This is easily recreated using any demo with txnFees
present and not present and reviewing the tradeStats() results.

--

Regards,

Michael Newell
OpenTrades
# 
Your observations are totally correct Michael.

Using txnFees != 0 is in fact a hack to be able to discern individual 
trades, but of course it only works under the conditions mentioned. In 
my strategies I usually specify 0 for entry transaction costs, then 
double the transaction costs for exits, but that will only work in 
certain strategies, true.

I am not aware of any plans to fix this at this point; patches (as 
always) welcome :-)
On 20-11-12 21:44, Michael Newell wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian G. Peterson
    

    

      
      #
    

  


  

      
On 11/20/2012 02:44 PM, Michael Newell wrote:

            

      
      
      
    

        
In the presence of transaction fees, you cannot really have a 
transaction with no P&L, can you?  (leaving aside a gain that precisely 
offsets the fees) so the count of transactions is indeed true.

There are three ways I can think of around this:
- one is to place the fees only on your flattening transactions, 
pretending that you only realize the fees when you exit the position...  
this isn't exactly true, but gets you what you seem to want.
- another would be to patch the function to allow a user-specified 
option to to use Gross rather than Net.
- or use perTradeStats instead, which uses position rather than P&L to 
separate 'trades'.  This function is newer than tradeStats, so perhaps 
the tradeStats function could be modified to use these instead of the 
simple PL>0 method.

Either of the latter two options shouldn't be a large change to the 
code, but I'm not likely to get to it any time soon. Patches Welcome.

Regards,

     - Brian