Multiple Data Series issue

I have the following code:
And I have two series on a given chart, both for the same equity, the first at 1 hour time interval, the second at 1 day time interval.

I also have the respective EMA 13 and 26 indicators visible on each of the charts (Moving Average Exponential).

Further, I have this as an entry signal: At the very last signal in the chart, the sma2 is shown visibly as > the fma2, but the print() shows that the signal sees otherwise. I am not sure why the signal is not calculating as expected, and why it is being triggered.

I am using IQFeed and MC 9.0, the latest release/patch.

Can someone give me some clues as to why this isn't working as expected?

Thanks much!

I have the following code:

Code: Select all

inputs:
close1(close of data1),
close2(close of data2),
fastma(13),
slowma(26);

variables:
fma(0),
sma(0),
fma2(0),
sma2(0);

fma = XAverage(close1, fastma);
sma = XAverage(close1, slowma);

fma2 = XAverage(close2, fastma);
sma2 = XAverage(close2, slowma);

And I have two series on a given chart, both for the same equity, the first at 1 hour time interval, the second at 1 day time interval.

I also have the respective EMA 13 and 26 indicators visible on each of the charts (Moving Average Exponential).

Further, I have this as an entry signal:

Code: Select all

if marketposition = 0 and (fma2 > sma2) then begin
if (close1 > fma) and (fma > sma) then begin
print (close1, fma, sma, " :", close2, fma2, sma2, " :", fma2[1], sma2[1]);
buy("op") next bar at market;
end;
end;

At the very last signal in the chart, the sma2 is shown visibly as > the fma2, but the print() shows that the signal sees otherwise. I am not sure why the signal is not calculating as expected, and why it is being triggered.

I am using IQFeed and MC 9.0, the latest release/patch.

Can someone give me some clues as to why this isn't working as expected?

Thanks much!

See post #5
[FAQ] Data2
viewtopic.php?f=16&t=6929

Thanks for the fast reply. I switched to this:
and I'm still seeing inconsistencies, and entries when the slow MA is < fast MA, except now I am seeing them when BOTH MAs are in the wrong relationship.

Did I miss something in that FAQ?

Thanks for the fast reply. I switched to this:

Code: Select all

inputs:
fastma(13),
slowma(26);

variables:
fma(0),
sma(0),
fma2(0, data2),
sma2(0, data2);

fma = XAverage(close, fastma);
sma = XAverage(close, slowma);

fma2 = XAverage(close, fastma) data2;
sma2 = XAverage(close, slowma) data2;

if marketposition = 0 and (fma2 > sma2) then begin
if (close > fma) and (fma > sma) then begin
print (close, fma, sma, " :", close data2, fma2, sma2, " :", fma2[1], sma2[1]);
buy("op") next bar at market;
end;
end;

and I'm still seeing inconsistencies, and entries when the slow MA is < fast MA, except now I am seeing them when BOTH MAs are in the wrong relationship.

Did I miss something in that FAQ?

Give this a try:

Go to Format Signal

Under the Properties tab

uncheck: Realtime-History Matching

I tried that, and have the same results.

I tried that, and have the same results.

I would start with an indicator...
PLOT the fma and sma lines.

in place of BUY/SELL... PLOT a dot.

THis should tell you where you stand.

Thanks for the tip, good idea.

However, this just makes it more confusing.

I'm plotting the 4 MAs on a single subchart, and with (or without RHM), the values are still not at the correct points to trigger the logic. I also notice that closer to the right of the chart, the values plotted on this new indicator are more-similar to the ones in the stock EMA indicator, but closer to where there is a problem with the signal, they have diverged quite a bit.

I have uploaded a screenshot of the divergent area.

I have always find it a challenge when mixing Intra-day analysis with Inter-day analysis.

Hmm, I was hoping that was a hint that you had better results with intra-day + intra-day. I changed the charts to 15m (data1) and 1hr (data2), and still see similar results as a I scroll back in time. The newer bars line up better, but much farther back, I find that they've diverged.

I am about to try the same strategy inside the Portfolio Trader to see if the results are better, but it seems like it will be painful to debug moving forward if the charts don't line up with what's inside Portfolio Trader.

Is anyone successfully doing this type of analysis with MultiCharts?

Well, the GOOD news is that the results are exactly the same in Portfolio Trader as they are on the chart.

Seems to me like that I'm either doing something completely wrong, or there's a fairly major issue somewhere.

Any other details I can provide to help resolve the issue?

I tried that, and have the same results.

"When Realtime-history matching option is enabled the signal/indicator is calculated on the latest bar of the main data series and on the currently completed bar of the auxiliary data series. If the auxiliary data series stops updating, the final calculation will be made on the main data series bar that was received immediately after the latest bar of the auxiliary data series. In this case no further calculation will be performed.
Note: If more than one auxiliary data series is used, the latest bar for the calculation will be the one that was completed earlier.
When Realtime-history matching option is disabled the signal/indicator is calculated on the basis of the main data series latest bar and current (completed or not) bar of the auxiliary data series. If the auxiliary data series stops updating, the calculation will continue on the basis of the latest bar of the main data series and the open bar of the auxiliary data series."

https://www.multicharts.com/trading-sof ... y_Matching

https://www.multicharts.com/trading-sof ... y_Matching

Thanks. I looked at this earlier when it was mentioned to toggle it, and after you posted, I read this specific section you copied about 4 times.

I am seeing exactly the same results with this setting toggled on vs. off. Just tried again.

At the rightmost bar(s), things look correct. As I scroll back in time, the indicators are correct, but the signal computation is wrong.

Perhaps my expectations are wrong?

Here's what I am expecting to see (conceptually):

data1 = 1 hour
data2 = 1 day

fma = 13 ema data1
fma2 = 13 ema data2

At rightmost bar - 100 (for example), I am expecting to see fma equal to the 13 EMA of bar 100 back through bar 113 back of the data1 series. I am also expecting to see fma2 equal to the 13 EMA of bar (about 15-16 back on data2 series) through bar 28-29 back of data2 series.

Am I missing a setting, code option, toggle, something? Or is this just not behavior I should expect? If the latter, how can I replicate these results?

Much appreciated...

Beejaysea, I can't understand either why there is no difference when same strat is toggled on and off alongside each other- nor why RTHM is enabled by default..

If RTHM makes a difference it would be useful to fully understand the precise implications since it makes absolutely no sense in my mind for MC to have auto enabled a facility which cannot be quantified by backtest and which automatically introduces lag into a signal since when enabled MC computes a signal for data1 based on the close of data2. This raises the question why MC have previously recommended that auxillary or secondary/tertiary data is of a lower(longer time frame) resolution than data1.

What if for instance a strat needs to compute on the current bar of data1 and the current bar of data 2 and execute intrabar of data1 - it appears from the MC description that bids or offers intrabar cannot be hit because MC has to wait for an update to data1 before it can issue an order.

Can MC Support please assist with these points - since I'm 10 months into this and none the wiser.

Thank you
Michael

Can MC Support please assist with these points - since I'm 10 months into this and none the wiser.

Are you seeing the same issue(s) then?

Beejaysea, I can't understand either why there is no difference when same strat is toggled on and off alongside each other- nor why RTHM is enabled by default..
l

Michael,

beejay's problem is not an RHM problem. Toggling RHM on or off will not change backtest. RHM on or off only makes a difference for realtime trading. RHM feature is provided to allow match of backtest and realtime results for poorly written code. Essentially, if RHM is disabled, then backtest and realtime results will mismatch for code that uses data2 without the use of barStatus(2) to sample the close of data2. This is because in realtime, with RHM disabled, the latest static data from series 2 (the 'in progress bar') is used in script calculation. This is not how backtest works since completed data2 bar instead of the 'in progress' bar is used in backtest. Proper code can be written to ensure that backtest and realtime results match even with RHM disabled. Also, if you want to do multidata, you will need to understand following 3 concepts well. They interact in subtle ways and only way to learn this stuff is by experimenting with code.

1. barStatus
2. series vs simple functions
3. the 3 idioms below:

"Proper code can be written to ensure that backtest and realtime results match even with RHM disabled. "


Thanks Orion,
Can you please supply a basic code example of how to match a backtest with realtime results with RHM disabled"

Thanks,
Michael

Can you please supply a basic code example of how to match a backtest with realtime results with RHM disabled"

The changes needed in improper (sloppy) code which has a mismatch between realtime and history are dependent on the nature of the code. The medicine depends on the disease the patient has. All trading should be done with RHM disabled and with the highest frequency data series as data1. Again, a deep dive into how barStatus, series functions, and those three idioms interact is the key.

Can you please supply a basic code example of how to match a backtest with realtime results with RHM disabled"

The changes needed in improper (sloppy) code which has a mismatch between realtime and history are dependent on the nature of the code. The medicine depends on the disease the patient has. All trading should be done with RHM disabled and with the highest frequency data series as data1. Again, a deep dive into how barStatus, series functions, and those three idioms interact is the key.

Orion, I use barstatus for data1 since after discussion with Christina some months ago it was explained (Barstatus(n)<>n worked only for data1 - which is why I requested you post an example that actually works? I arrived too at your view on RHM some months ago and cannot understand why it is the default setting since real time results will closer resemble backtest when RTHM is switched off.

Any basic wrapper you have using 2 or 3 data which you know works will be useful?

Thanks,
Michael

3. the 3 idioms below:

Code: Select all

1. vars: myvar (0, data2);
2. value1 = rsi(close of data2, 14);
3. value1 = rsi(close of data2, 14) data2;

I agree here, it seems like my issue is not with RHM.

Here's my indicator:
I've tried all of these:
and also with and without the barstatus(2) condition.

None of the results for the fma2 and sma2 values match the 13 EMA and 26 EMA of data2 on the data2 chart.

Quick glance at your code and one problem is you are using a series function inside a conditional.

Quick glance at your code and one problem is you are using a series function inside a conditional.

Thanks.

I removed the conditional, same issue.

Yes, that is expected behavior!

Take the following code for myXaverage(). Verify that it is identical to the builtin xaverage() function you are using except for the print statement that has been inserted. Save this code and compile it as a function. Use auto-detect for the function setting when compiling. Now compile the following as an indicator and insert it in a chart. Any chart will do. Yes, you are reading this right. It is a single line of code with an if statement that is always true. Run it. Now change the if conditional to "false" so that it is always false. Run it. Do you see a difference?
This is all for now. I have given you all the pointers in the prior emails.

Thanks for the pointers.

Using the clues in your posts, I switched to Average() from XAverage(), as well as using regular MA as the stock indicators. Everything seems to work as expected with Average().

Now, to figure out how to make it all work with EMA.

Welcome! You have graduated from novice status. Making ema work will get you to PL expert status. All the best.

Yes, that is expected behavior!

Take the following code for myXaverage(). Verify that it is identical to the builtin xaverage() function you are using except for the print statement that has been inserted. Save this code and compile it as a function. Use auto-detect for the function setting when compiling.

Code: Select all

inputs:
PriceValue( numericseries ),
Len( numericsimple ) ;

variables:
var0( 2 / ( Len + 1 ) ) ;

print (currentBar:0:0);
if CurrentBar = 1 then
myXaverage = PriceValue
else
myXaverage = myXaverage[1] + var0 * ( PriceValue - myXaverage[1] ) ;


Now compile the following as an indicator and insert it in a chart. Any chart will do. Yes, you are reading this right. It is a single line of code with an if statement that is always true. Run it. Now change the if conditional to "false" so that it is always false. Run it. Do you see a difference?

Code: Select all

if (true) then myXaverage(close, 20);

This is all for now. I have given you all the pointers in the prior emails.

Hi Orion,
Compiling Xaverage with the print statement as per your example and separate 1 line indicator I get the same print statement output both when True and False - which appears to undercount the first 4 bars ie: 1,2,1,2 - so is this your point and if so what approach have you adopted?

Cheers,
Michael

Michael, I was away and hence the delayed response. If this is still an open issue, the point I was trying to make is that XAverage() is a series function as opposed to a simple function. While a simple function executes only when called by logic, a series function executes on every bar even if not called from your code. Hence use of series functions requires special care in your code. In my scripts, I have solved this quirkiness of series functions by creating simple versions of all series functions.

Michael, I was away and hence the delayed response. If this is still an open issue, the point I was trying to make is that XAverage() is a series function as opposed to a simple function. While a simple function executes only when called by logic, a series function executes on every bar even if not called from your code. Hence use of series functions requires special care in your code. In my scripts, I have solved this quirkiness of series functions by creating simple versions of all series functions.

Thank you Orion, that may well explain why I have such variability of results between backtest/dataplayback and live! Though I'm not so sure I understand how you manage to create a simple function from a series function - do you bury the series element in the function making it a variable activated by barstatus or another condition? If it isn't too much could you possibly give an example?

Thanks

Michael

Michael, please find code for simple version of XAverage(). The trick is to use an input to pass the value of the old average into the call for the new calculation. The caller must save the value of old average from the previous call and pass it in the new call. The value of the old average is ignored on the first call (when initFlag is true) since the value passed by the caller is garbage on the very first call. Unlike the series version of XAverage(), this can be called conditionally from your code and it will execute only when called.

Note that when doing multidata you will need to use barStatus conditionals in your code. These barStatus conditionals are useless for series functions since EL/PL language semantics require that series functions are evaluated unconditionally on each bar. This unconditional execution of series functions is a big landmine for unsuspecting users. The simple version of XAverage() below is free of this landmine issue. It is to avoid these landmines that I have converted all series functions to simple functions in my scripts.