+1 888 340 6572
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
feature_request_small.png
Open Feature request MC-1439

Strategy won't calculate until open of next Data2 bar

action_vote_minus_faded.png
8
Votes
 action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

I've reported this problem 3 years ago and worked around it at the time. This is a very fundamental yet commonly encountered problem I cannot understand why after all these years it is still here.

What it is:

  • The calculation of studies in MC happens at the open of "next bar" which is what it should be no problem here.

  • However, if a strategy has any references to more than one data series, the whole strategy won't calculate until a new bar of that series is created. For example if a strategy has referenced Data2 the whole strategy won't calculate until there is a new Data2 bar created.

  • That means if Data1 has a session end time of 15:15 and Data2 has a session end time of 15:00, the whole study won't calculate from 15:00-15:15 everyday in real-time trading until the next morning when there is a new Data2 bar created.

  • Under back-testing this happens only on the last session end on chart because we have a new Data2 bar at every session end in historical back-testing except for the last session on chart. However in real time this is a daily problem and a very serious one! The strategy simply stops calculating until the next day!!!

  • This creates a huge problem when we have multiple data series on a chart because many times we have different session end time among those data series.

  • On Tradestation the implementation is correct and we don't have this problem. Not so on MC. I've attached screenshots for both Tradestation and MC.

Steps to reproduce this issue

I have provided with sample data and code and screen shot for TSS to reproduce this problem. Which is very straight forward to reproduce:

Data1: ES future 1 min intraday day session with session end time 15:00
Data2: S&P 500 index 1 min intraday session with session end time 15:15

Strategy Code:

if date data2 date[1] data2 then buy this bar close;
if time >= 1505 then sell this bar close;

What to expect:
- On the last session on chart the strategy won't sell at 1505 because no new Data2 bar has been created and the strategy stopped calculating since 1500

What it should be:
- The strategy should continue to calculate since there is still new data bars creating on Data1!!!

IMHO this is a very high priority bug as it affects basic calculations whenever the study uses more than 1 data series with different session end time!!! I'm totally surprised this bug is still here since I have reported it in full detail since MC 5.5 or 6.0.

Comments (24)
icon-mono-settings.png
#0
user-offline.png glam_100 (glam_100)
Sep 02, 2013 - 15:28

Someone on discussion forum suggested me to uncheck "real time historical matching"
Here's my reply:
Thanks for the reply. Un-checking that option doesn't solve the fact that during real-time trading the signal will stop calculating until the next bar of Data2 appears, which is tomorrow.
The correct implementation should be as long as Data1 has new bars the signal should continue to calculate and use the last Data2 bar value for study calculation should the signal reference any data2 values.This is how tradestation implements and IMHO the only sensible way to implement. The current MC implementation makes it impossible to continue trading once the shortest data series session has ended. This is unacceptable for example one would trade a 24 hour forex symbol (say the USD/JPY) and may take other data series as input (say the S&P index) which only has a 8 hour session. In this case the study will stop calculating once the S&P session has closed despite what we want to trade is the 24 hour forex symbol.

#0
user-offline.png glam_100 (glam_100)
Sep 02, 2013 - 17:31

The correct implementation should have studies continue to calculate as long as there is a new bar created on ANY of the data series.
For data series that have ended early in the session the value of the last bar should be used for the calculation.

#0
user-offline.png glam_100 (glam_100)
Sep 02, 2013 - 17:40

The correct implementation should have studies continue to calculate as long as there is a new bar created on ANY of the data series.
For data series that have ended early in the session the value of the last bar should be used for the calculation.
This is the DIRECT OPPOSITE of the current MC approach where studies stops to calculate as long as there is no new bars on ANY of the data series.
It should be an easy logical fix on the condition of when to stop calculation but a very important fix for those who use more than one data series in their studies.

#0
user-offline.png glam_100 (glam_100)
Sep 02, 2013 - 17:55

The correct implementation should be this:
For indicators/studies:
- The calculation should continue as long as there is a new bar created on the series that indicator/studies is based on.
For strategies/signals:
- The calculation should continue as long as there is a new bar created on Data1. This is because a strategy/signal calculation is always based on Data1.
For data series that have ended early in the session the value of the last bar should be used for the calculation.
It should be an easy logical fix on the condition of when to stop calculation but a VERY IMPORTANT fix for those who use more than one data series in their studies.

#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 02, 2013 - 19:57

Do i understand you correctly that you want your indicator to continue being calculated on data1 and use latest available values from data2 no matter if the data2 is not updating?

#0
user-offline.png glam_100 (glam_100)
Oct 03, 2013 - 08:59

Hi Andrew,

Yes you understand me correctly. I want the strategy/indicator to continue being caluclated on data1 and use the latest completed bar value from data2 ...etc even if data2 is not updating. This is a necessary fix for anyone who what to use multiple data feeds with different ending sessions to trade in real time without disabling the "Realtime-history matching" option. The "realtime history matching" disable option is not the correct solution to this problem. Disabling it makes MC calculate on NON completed bars and thus making realtime calculation very different from historical backtesting.

With the above option both historical and real-time calculation will be exactly the same and the "Realtime-hisotry matching" option is not needed anymore. The "realtime history matching" option was added 3 years ago as a response to this exact problem reported by me at the time. At the time I worked around the problem and never got back to MC again about that option not being able to do what I was referring to.

This is the way tradestation solves this problem. We won't find any "realtime historical matching" option there. It is really dangerous to allow the program to calculate differently in realtime than in backtesting. Unsolphisticated users may not even know their realtime calculation is different from their historical backtesting when they disable the "realtime historial matching" option.

#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 03, 2013 - 22:06

Please see the attached screenshot demonstrating how MC calculates scripts when the feature is disabled. If you require a different behaviot, please provide me with an examplу that is currently not possible.

#0
user-offline.png glam_100 (glam_100)
Oct 04, 2013 - 05:51

I have attached a screenshot.
1) Realtime history match enabled - At Data1 Bar 1 (14:55), MC will use Data2 Bar A value at 14:55. At Data1 Bar 2 (14:56), MC will use Data2 bar A value from 14:55.
2) Realtime history match disabled - At Data1 Bar 1 (14:55), MC will use Data2 bar A value at 14:55. At Data1 Bar 2 (14:56), MC will use non-completed Data2 Bar B value from 14:56 in realtime.
Using Data2 Bar B value from 14:56 will realtime and backtest calculation different.
The correct way is to continue using Data2 Bar A (14:55) for calculation just like Option 1).
When Data2 stopped updating simply use the last completed Data2 Bar and continue calculation.
For example at Data1 Bar 7 (15:01), use Data2 Bar B (15:00) for calcluation.
What I'm asking is simply option 1) (Realtime history match enable) but continue to calculate even when data2 stops updating.

#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 04, 2013 - 17:36

All the following examples are true if script/study/signal/strategy is applied to/based on data series 1.
'Real-Time History Matching' is turned off (the box is cleared), the data series 1 continues updating, the data series 2 stopped updating: a script will be calculated on data series 1 using the updating values from data series 1 and the latest static available values from data series 2. Please see the OFF_Data1_tick_Data2_stop.PNG.
'Real-Time History Matching' is turned off (the box is cleared), the data series 1 stopped updating, the data series 2 continues updating: a script will be calculated on the latest bar of data series 1 and will not be calculated until new ticks/bars come in on data series 1, no matter if data series 2 is updating or not. At the moment of this last calculation of the script the latest values of data series 2 are used. Please see the OFF_Data1_stop_Data2_tick.PNG.
'Real-Time History Matching' is turned on (the box is checked), the data series 1 continues updating, the data series 2 stopped updating: a script will be calculated on a historical bar of data series 1 and will not be calculated until new ticks/bars come in on data series 2, no matter if data series 1 is updating or not. Please see the ON_Data1_tick_Data2_stop.PNG.
'Real-Time History Matching' is turned on (the box is checked), the data series 1 stopped updating, the data series 2 continues updating: a script will be calculated on the latest bar of data series 1 and will not be calculated until new ticks/bars come in on data series 1, no matter if data series 2 is updating or not. At the moment of this last calculation of the script the corresponding (not the latest) values of data series 2 are used. Please see the ON_Data1_tick_Data2_stop.PNG.

It seems to me that what you are requesting is already possible with the underlined variant. Or the whole point of the feature request is not to use values from bar B and use values from bar A, if the bar B is opened, but not yet closed?

#0
user-offline.png GB (Id2)
Oct 07, 2013 - 04:47

Or the whole point of the feature request is not to use values from bar B and use values from bar A, if the bar B is opened, but not yet closed?
EXACTLY!!! You've got it!!!

Edit Delete
#0
user-offline.png GB (Id2)
Oct 07, 2013 - 04:49

If we don't use value from bar B when it is not yet closed, then there is not need for "realtime history matching"!!!!
This is how tradestation calculate... check it out

Edit Delete
#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 07, 2013 - 20:12

You can add a simply improvement to you script to check the barstatus of the data2 in order to make it work the way you want.

#0
user-offline.png GB (Id2)
Oct 08, 2013 - 05:31

Why can't MC simply make it right and not use bar B when it is not yet closed?
Using bar B when it's not closed will make realtime and history calculation not match which should never be allowed to happen!

Edit Delete
#0
user-offline.png GB (Id2)
Oct 08, 2013 - 05:46

I'm not even sure if it is possible to achieve what I want by checking the barstatus of data2. My code are all mixed up with data1 and data2 and if I check the barstatus of data2 for bar close all the data1 code may not run until the bar close of data2 which is of course not what I want.

Edit Delete
#0
user-offline.png GB (Id2)
Oct 08, 2013 - 05:55

Then I will have to change all the code and put all data2, data3, data3 code ...etc into variables accordingly and bracket each of those with barstatus(1), barstatus(2) check ...etc.
That will be too much work!

Edit Delete
#0
user-offline.png GB (Id2)
Oct 08, 2013 - 06:02

I strongly urge MC to use closed Bar A to calculate instead of unclosed Bar B.
Is there any benefit to use unclosed Bar B for calculation?
It allows for the dangerous real-time and history mis-match which should never be allowed to happen.
At the very least can you add an option to use closed Bar A for calculation?
Thanks!

Edit Delete
#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 08, 2013 - 14:55

This feature is not scheduled for any coming version of MultiCharts at the moment. This reuest has 0 votes.
I suggested you a workaround to reach your goal.
If you are interested in us to implement it for you on the paid basis, please send us an email to support@multicharts.com.

#0
user-offline.png GB (Id2)
Oct 09, 2013 - 06:24

Andrew, this calculation issue is not obvious. No one is going to vote for it.
I've been with MC since MC 1.x when you were the one who's supporting all the users on live chat. I think you would understand realtime historical calculation mis-match is an important issue with or without user vote. I certainly don't have time to bring this out on the forum and raise awareness or start a campaign on voting for this issue.
I hope this will be fixed in future version of multichart because to me this is the final last problem with MC since the first day about 7 years ago when everything were so problematic. I have to continue using tradestation + owndata for trading even today whenever I use more than 1 datafeed in realtime. With this fix MC will finally be perfect and I can ditch tradestation for good.
Please consider this fix and making MC perfect. Thanks!

Edit Delete
#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 09, 2013 - 10:30

Well, i understand your point, but to tell the truth i don't quite understand why you need this feature. In real-time it always takes current value from data2, no matter if the cusrrent bar of data2 is closed or is in progress. This scenario is possible for backtesting since we introduced "real-time history matching" feature:
If for a reason you need to reference values from second series from only closed bars, you can do it in your strategy script, but it is not like it works in real-time calculation.

#0
user-offline.png GB (Id2)
Oct 10, 2013 - 10:09

I need this feature for the same reason we use closed bar on Data1 for calculation. In backtest or in realtime we need to use closed bar on data1. If we use in-progress bar on data1 the calculation will be wrong. This is the exact problem I face now with Data2.

Edit Delete
#0
user-offline.png GB (Id2)
Oct 10, 2013 - 10:17

If we always take current value from data2 in realtime, it would be like forcing me to use Intrabar Order generation.

Edit Delete
#0
user-offline.png MultiCharts Support (MultiCharts)
Oct 10, 2013 - 12:56

I confirm it does take current value from data2 when calculating in real time. If you want to work it different way it not just the matter of "real-time history matching" feture. Once again, if you neeed it right now, you can adjust your strategy script to check barstatus of data 2 and reference last bar or previous bar of data depending on current barstatus.

#0
user-offline.png GB (Id2)
Oct 11, 2013 - 05:30

If I enable "real-time history matching" feature the strategy will stop once data2 stops updating (ie. the screenshots I posted earlier). I need the strategy to continue calculation as long as data1 continue to update.
For the mean time I can work around and check barstatus of data2. This is like coding for intrabar order generation making the script more complicated.
Thanks so much!

Edit Delete
#0
user-offline.png GB (Id2)
Oct 22, 2013 - 08:31

I have created a thread that is much easier to understand and ask for people to vote for this:
http://www.multicharts.com/discussion/viewtopic.php?f=1&t=45508&p=99053#p99053
Thanks so much!

Edit Delete
History
sidebar_collapse.png sidebar_expand.png
Issue basics
  • Type of issue
    Feature request
  • Category
    Usability
  • Targeted for
    Not determined
  • Status
    Not a bug
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (2)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    Not determined
  • Severity
    Critical
Attachments (8)
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates