Profile Picture

Daily frequency problem on 1 minute system

Posted By Steve2008 7 Years Ago
Message
Posted Saturday August 21 2010
I added code for daily frequency handling to a system that runs on 1 minute bars, based on the example code in the documentation under "What's New in This Edition," and found in backtesting that the system results were arbitrarily different.

The system is running on 1500 stocks for 2 weeks of 1 minute bars, with a fixed dollar allocation per trade and enough capital so that there are no trades rejected on account of insufficient capital.

I commented out my daily frequency code piece by piece until narrowing down the problem to one statement in Startup() within MySymbolScript: "DailyFreq = GetFrequency(BarFrequency.Daily);" The definition for DailyFreq is in MySymbolScript: "Frequency DailyFreq;"

With all of the daily code commented out except for the DailyFreq definition, I get 85 trades at an average profit of .37%, exactly the same results as with the version of the system before I added daily code. With the offending statement not commented out, I get 103 trades with an average profit of .30%.

This should not be happening. All other daily code was commented out for purposes of isolating the problem, and the code above should have zero effect on the system results.

The daily code I added was to calculate dollar volume for the previous day, from volume * close, and to filter out trades based on a minimum dollar volume. Aside from the problem noted above, the code apparently worked properly. I had it display the daily volume and close, and the numbers were plausible.

I'm not doing anything unusual in my system code, which is all in MySymbolScript.

I don't know whether I have uncovered a known or unknown bug in frequency handling, or whether I am doing something wrong. Please advise.

Thanks.

UPDATE: In an apparently separate issue, with my daily code un-commented out, in NewDailyBar when trying to add new functionality I get the error below when I refer to a lookback of greater than 0, such as 1 or 10, e.g.:

if (DailyFreq.Close.LookBack(0) > DailyFreq.Close.LookBack(1))

An exception of type System.ArgumentOutOfRangeException was thrown.
Value must be between 0 and 0, value was 1
Parameter name: nBars
   at RightEdge.Common.RList`1.LookBack(Int32 nBars)
   at RightEdge.Common.x92be11e4ace82e40.LookBack(Int32 nBars)
   at MySymbolScript.NewDailyBar(Object sender, SingleBarEventArgs args) in c:\Users\Me\Documents\My RightEdge Trading Systems\tst1\tst1.cs:line 250
   at RightEdge.Common.Frequency.OnNewBar(SingleBarEventArgs args)
   at RightEdge.Common.FrequencyManager.SendPendingBars()
   at RightEdge.Common.FrequencyManager.UpdateTime(DateTime dateTime)
   at RightEdge.Common.FrequencyManager.ProcessBar(SingleBarEventArgs newBar)
   at RightEdge.Common.Internal.SystemRunner._tickGenerator_NewBar(Object sender, NewBarEventArgs e)
   at RightEdge.Common.TickGenerator.ProcessBar(NewBarEventArgs args)
   at RightEdge.Shared.SystemWrapper.RunSystem(SystemData systemData, SharedSystemRunData runData, ServiceFactory brokerFactory)
   at RightEdge.Shared.SystemWrapper.RunSystem(String filename, ServiceFactory brokerFactory, PluginSettings dataStoreSettings)
   at RightEdge.Shared.SystemWrapper.RunSystem(String filename, ServiceFactory brokerFactory, PluginSettings dataStoreSettings)
   at RightEdge.Shared.TradingModuleWrapper.Run(String filename)
   at RightEdge.Shared.TradingModuleWrapper.RunSystem(SharedSystemRunData systemRunData)
   at RightEdge.SystemProgress.InitAndRunSystem()


Edited: Saturday August 21 2010 by Steve2008
Posted Tuesday August 24 2010
I wrote a simple system in an attempt to isolate this.  Do you think you could run against a simplified set of data?  If I understand you correct, the line DailyFreq = GetFrequency in Startup causes different results.  I'm not able to reproduce it, but I may not have the same data to make it happen.  Can you take my simple system and run against a small amount of data and make it happen?  When we get that, I can put it under the microscope and see what's going on.

With regard to your second issue, there aren't enough bars in the lookback.  You're going back 1 bar when there are 0 bars.  So do a bounds check to make sure you have enough bars to lookback.

public class MySymbolScript : MySymbolScriptBase

{

      Frequency DailyFreq;

      BollingerBandLower bbl;

     

      public override void Startup()

      {

            // Perform initialization here.

 

            DailyFreq = GetFrequency(BarFrequency.Daily);

            bbl = new BollingerBandLower(14, 2.0);

      }

 

      public override void NewBar()

      {

            // Put your trading code here

            OpenPosition(PositionType.Long, OrderType.Limit, bbl.Current);

      }

}

Steve2008 (8/21/2010)
I added code for daily frequency handling to a system that runs on 1 minute bars, based on the example code in the documentation under "What's New in This Edition," and found in backtesting that the system results were arbitrarily different.

The system is running on 1500 stocks for 2 weeks of 1 minute bars, with a fixed dollar allocation per trade and enough capital so that there are no trades rejected on account of insufficient capital.

I commented out my daily frequency code piece by piece until narrowing down the problem to one statement in Startup() within MySymbolScript: "DailyFreq = GetFrequency(BarFrequency.Daily);" The definition for DailyFreq is in MySymbolScript: "Frequency DailyFreq;"

With all of the daily code commented out except for the DailyFreq definition, I get 85 trades at an average profit of .37%, exactly the same results as with the version of the system before I added daily code. With the offending statement not commented out, I get 103 trades with an average profit of .30%.

This should not be happening. All other daily code was commented out for purposes of isolating the problem, and the code above should have zero effect on the system results.

The daily code I added was to calculate dollar volume for the previous day, from volume * close, and to filter out trades based on a minimum dollar volume. Aside from the problem noted above, the code apparently worked properly. I had it display the daily volume and close, and the numbers were plausible.

I'm not doing anything unusual in my system code, which is all in MySymbolScript.

I don't know whether I have uncovered a known or unknown bug in frequency handling, or whether I am doing something wrong. Please advise.

Thanks.

UPDATE: In an apparently separate issue, with my daily code un-commented out, in NewDailyBar when trying to add new functionality I get the error below when I refer to a lookback of greater than 0, such as 1 or 10, e.g.:

if (DailyFreq.Close.LookBack(0) > DailyFreq.Close.LookBack(1))

An exception of type System.ArgumentOutOfRangeException was thrown.
Value must be between 0 and 0, value was 1
Parameter name: nBars
   at RightEdge.Common.RList`1.LookBack(Int32 nBars)
   at RightEdge.Common.x92be11e4ace82e40.LookBack(Int32 nBars)
   at MySymbolScript.NewDailyBar(Object sender, SingleBarEventArgs args) in c:\Users\Me\Documents\My RightEdge Trading Systems\tst1\tst1.cs:line 250
   at RightEdge.Common.Frequency.OnNewBar(SingleBarEventArgs args)
   at RightEdge.Common.FrequencyManager.SendPendingBars()
   at RightEdge.Common.FrequencyManager.UpdateTime(DateTime dateTime)
   at RightEdge.Common.FrequencyManager.ProcessBar(SingleBarEventArgs newBar)
   at RightEdge.Common.Internal.SystemRunner._tickGenerator_NewBar(Object sender, NewBarEventArgs e)
   at RightEdge.Common.TickGenerator.ProcessBar(NewBarEventArgs args)
   at RightEdge.Shared.SystemWrapper.RunSystem(SystemData systemData, SharedSystemRunData runData, ServiceFactory brokerFactory)
   at RightEdge.Shared.SystemWrapper.RunSystem(String filename, ServiceFactory brokerFactory, PluginSettings dataStoreSettings)
   at RightEdge.Shared.SystemWrapper.RunSystem(String filename, ServiceFactory brokerFactory, PluginSettings dataStoreSettings)
   at RightEdge.Shared.TradingModuleWrapper.Run(String filename)
   at RightEdge.Shared.TradingModuleWrapper.RunSystem(SharedSystemRunData systemRunData)
   at RightEdge.SystemProgress.InitAndRunSystem()

Posted Tuesday August 24 2010
Thanks for your response.

I can't replicate the problem using the simple system (which is the sample Bollinger Penetration, and which needs a set inputs statement) with a 30 bar exit.

However, I can consistently replicate the problem with my own system.

I will have to check further to see if I can identify what is causing the problem.

Posted Friday August 27 2010
The difference in backtest results with or without "DailyFreq = GetFrequency(BarFrequency.Daily);" only happens when synchronize bars is set to false. I am working with 1 minute bars on a large watchlist of stocks, and when downloading historical data from IQFeed I see that many of them do not have bars for each minute. This suggests that 1) I need to set synchronize bars to true, which makes this whole issue moot, and there is no need to further isolate what in my code is causing this; 2) the daily frequency code triggers different handling of missing bars.

Does this sound correct?

Regarding what synchronize bars does:

1) If there is no bar, does it create a bar in memory for processing purposes, without changing the data store on disk, with the OHLC all equal to the close of the previous bar, with a volume of zero, and repeat this for repeated missing bars? If not, what does it do?

2) Does it operate on both a live system and in backtesting?

3) Is information about bar synchronization processing available in the API for use by a trading system? This could be useful in assessing the liquidity of a security.

Thanks.

UPDATE: To clarify, I still cannot replicate the daily frequency results difference with the simple Bollinger penetration system with or without bar synchronization enabled, but I can with my system. My system does not use RE indicators or custom indicator plugins, but creates the equivalent of an indicator by doing calculations within the symbol script from the closes of the last N bars.

Steve2008 (8/24/2010)
Thanks for your response.

I can't replicate the problem using the simple system (which is the sample Bollinger Penetration, and which needs a set inputs statement) with a 30 bar exit.

However, I can consistently replicate the problem with my own system.

I will have to check further to see if I can identify what is causing the problem.


Edited: Friday August 27 2010 by Steve2008
Posted Friday August 27 2010
If there is no bar, does it create a bar in memory for processing purposes, without changing the data store on disk, with the OHLC all equal to the close of the previous bar, with a volume of zero, and repeat this for repeated missing bars?


Yes, this is what it does. It only creates a bar for a given time if there was some symbol with a bar though. So if none of your symbols have data for a given time, it won't create any bars.

Does it operate on both a live system and in backtesting?


Yes

Is information about bar synchronization processing available in the API for use by a trading system?

The bars which are created have the EmptyBar property set to true. However, in most cases I don't think you would care whether the bar was in your data store with a volume of zero, or was created by bar synchronization with a volume of zero.

The difference in backtest results with or without "DailyFreq = GetFrequency(BarFrequency.Daily);" only happens when synchronize bars is set to false. I am working with 1 minute bars on a large watchlist of stocks, and when downloading historical data from IQFeed I see that many of them do not have bars for each minute. This suggests that 1) I need to set synchronize bars to true, which makes this whole issue moot, and there is no need to further isolate what in my code is causing this; 2) the daily frequency code triggers different handling of missing bars.
Does this sound correct?


This sounds correct. Do you have CreateTicksFromBars set to true or false? If it is set to false, and you are only using one frequency (which matches the system frequency), then RightEdge skips a lot of the frequency processing, and it's possible there is an issue with how it handles SynchronizeBars.

Can you add code to record the BarStartTimes for each bar generated? Then set SynchronizeBars to false and compare the results with and without the line of code that adds the daily frequency enabled.

Thanks,
Daniel
Posted Saturday August 28 2010
I have CreateTicksFromBars set to false.

On the illiquid stock AAON, on 8/24/2010 I get 80 one minute bars with identical start times with or without the daily frequency code line.

UPDATE: I added code to count the number of total bars for all symbols combined. On 1500 stocks, with bar syncronization off, the total bar count is identical with or without the frequency code, but the backtest results are different. This is with max open = 0 and restrict orders = false.


Edited: Saturday August 28 2010 by Steve2008
Posted Sunday August 29 2010
I think we need to figure out more details on how the results are differing. Can you compare the fills generated? You can either add code to your system that logs each fill, or you can export the fills from the system results screen. Either way, then use a diff tool (I like WinMerge) to see what's difference.

Thanks,
Daniel
Posted Sunday August 29 2010
Since I need to set synchronize bars to true, and this issue occurs only when it is set to false, this is not an issue that I would choose to invest further time in.

However, if you feel that my spending further time on this may help you identify and fix a possible problem in RE, I am willing to assist.

I would like to make sure we are on the same page regarding the reasons for pursuing this before I put in additional time.

Thanks.

Posted Tuesday August 31 2010
It looks like there might be an issue with RE here, so I'd appreciate it if you could help us track it down. You don't need to feel obligated to do so, and if it is going to be a lot of time on your part I wouldn't worry about it.

Thanks,
Daniel
Posted Tuesday August 31 2010
I e-mailed you a trading system that replicates the problem, and associated information, including system results files.


Similar Topics


Reading This Topic


2005-2017 © RightEdge Systems