|
|
|
|
The indicators I have setup determine the values for the active bar based only on previous values. These indicators are a mix of IndicatorBase, and SeriesCalculatorBaseWithValues base types. In order to analyze these indicators in the context of current market activity I need to be able to access the values during the formation of a new bar.
It seems that simulations and live systems handle this differently, which I assume is because the paper broker doesn't yet handle ticks. I hope that when the paper broker implements tick level processing these interfaces will converge. Having separate logic for live vs. backtest modes is always more work to implement, and potentially dangerous.
For now, I've been testing using the BarOpened event and the paper broker. It seems that the BarData passed to the event handler is not in the Bars list, and thus the indicator values have not yet been calculated. I would presume that the NewTick() partialBar is in a similar state when running a system live.
So, how can I access my indicator values for the "real" current bar, not the last completed?
Thanks,
Mark
|
|
 Posted 4/5/2008 20:48:11
|
|
|
|
| At this point, you can't because our indicator system only runs on completed bars. We do not recalculate indicators during ticks (even in live). It would be nightmare for performance in a lot of cases. At this point the only way to handle this is to do it within a system, and of course that means you cannot have parity with simulations. When tick level testing is added to simulation the plan is for there to be complete parity. I am not sure what the plan is an interface for and proper tick level indicators, so maybe Bill or Daniel could chime in.
|
|
|
Posted 4/6/2008 07:36:07
|
|
|
|
Thanks for the quick response!
I can understand how recalculating every tick could become a CPU hog, however getting this to work is critical for my particular setup. In my case, the indicator values are known at bar open and remain constant throughout the bar's formation, so the performance impact would be minimal. (The indicators don't use the 'Current' property, only LookBack(1+x)'s where x>=0.)
I tried playing around with the UserSeries class, but when it is registered with the series manager I run into the same problem. How would you recommend I handle this inside the system?
In thinking about "proper tick level indicators", What if indicators had a flag like 'CalcInsideBars' similar to 'TradeInsideBars'? The newly opened bar could be added to the 'Bars' list on the first tick (ie the BarOpened event), then all indicator values could be calculated for the current (active) bar. On subsequent ticks, only the current bar and the flagged indicators would need to be updated.
Thanks again,
Mark
|
|
|
Posted 4/6/2008 09:25:05
|
|
|
|
| Although it might be problematic, CPU use isn't the only reason we don't currently support this. The indicator interface would also have to change, and it would be more complicated to write indicators. That is because each time a tick comes in, the current value would have to be recalculated. (This wouldn't be necessary in your specific case since it only uses the open value, but for most indicators it would be.) I think that right now the easiest thing would be to do your calculations without using any of the built-in indicators at all. If that ends up being too complicated you could create an indicator and call it's NewBar() method from your BarOpened handler. You would want to prevent the indicator manager from calling NewBar on it when a new bar comes in, and you can do this by putting the indicators in a separate "wrapper" class like your IndicatorSuite, and not registering them with the indicator manager. The paper broker does currently process ticks, however in the released version it does it incorrectly when you are running with more than one symbol. The BarOpened and BarClosing events are currently only called in backtesting mode. Thanks,
Daniel
|
|
|
Posted 4/7/2008 10:17:06
|
|
|
|
Thank you for the input Daniel, I've been playing around with your suggestions. I didn't want to lose the features of a registered indicator (charting, etc..), so I've settled on extending the indicator classes myself. I simply added a member variable for the currently active bar's indicator value. The BarOpened()/NewTick() handlers generate this value from the partial bar and my analytic classes now take this extra value into account. Everything is looking good now 
dplaisted (4/6/2008)
The paper broker does currently process ticks, however in the released version it does it incorrectly when you are running with more than one symbol. The BarOpened and BarClosing events are currently only called in backtesting mode.
If I understand you correctly regarding the events that are fired in live vs sim mode:
In Simulation mode, only BarOpened() and BarClosed() are fired.
In Live mode, only NewTick() is fired.
Thus, in live mode my system would receive the NewTick() event, even if running against the paper broker?
|
|
|
Posted 4/7/2008 10:24:15
|
|
|
|
mark0419 (4/7/2008)
In Simulation mode, only BarOpened() and BarClosed() are fired.
In Live mode, only NewTick() is fired.
Thus, in live mode my system would receive the NewTick() event, even if running against the paper broker?
This is correct. In the future we will probably allow BarOpened and BarClosing to be raised when running a live system, and we will support tick-level backtesting which would cause NewTick() to be fired in simulation mode. Thanks,
Daniel
|
|
|
|