EFS multiple intervals question

[z11]

in EFS2, true synchronization with external intervals would only be achieved if calling interval is some multiple of external intervals, such 1x3x15, etc.

Can we really achieve synchronization with an EFS calling from a tick chart ( or a volume chart or a range chart) with external intervals that are time based or another (tick/volume/range) chart combination?

ziggy

[ACM]

ziggy
To my knowledge intervals of different types cannot be uniformly synchronized.
Multiple time frame studies are synchronized by the time stamps of the bars and because these are not correlated when using tick based intervals there is no logical way to accomplish that.
Alex

Originally posted by z11
in EFS2, true synchronization with external intervals would only be achieved if calling interval is some multiple of external intervals, such 1x3x15, etc.

Can we really achieve synchronization with an EFS calling from a tick chart ( or a volume chart or a range chart) with external intervals that are time based or another (tick/volume/range) chart combination?

ziggy

[mikejhelms]

I agree that it is logically impossible to perfectly synchronize two tick charts. So what process is the synchronization engine using now to approximate synchronization assuming the study is not set to “Compute on Close?” For example, assume the calling EFS is in a 100 tick chart. Consider when the internal symbol’s fiftieth and fifty-first ticks are generated and the time between when they are generated. The external or called symbol can do one of four things:

1. generate two ticks that are simultaneous with the two internal ticks(no problem).
2. not generate a tick
3. generate one tick between the time of the internal’s two ticks.
4. generate more than one tick between the time of the internal’s two ticks .

How does it handle the last three situations? Thanks.

Mike

[mikejhelms]

The reason I ask the previous question is that I'm looking for a reason why if the internal EFS generates a Moving Average of the externally called symbol in real-time, that moving average is different if you put the study up after hours. I realize that the synchronization the engine is attempting must be an approximation but I would think it would use the same approximation algorithm after hours as it uses in real-time. Thanks again.

Mike

[eSignal_JasonK]

Hello Mike,

In real time the comparison is taking into consideration the most current tick intra-bar, which will not be seen if you load the study after hours as that data will be based on the closing values of the bars. Does this help?

If not you may need to post some code and some chart images to better illustrate what you are referring to.

[mikejhelms]

Here’s an example I ran today. The study pictured in the next post, “Jason Demo”, on a 200 tick chart of the e-mini during market hours today generated the top graph.

function main() {
if (getCurrentBarIndex() != 0) return;
return sma(5, sym("eprem a0"));
}

After the market closed I put a slightly altered second study, “Jason Demo After Market Closed” on the chart which generated the second graph. As you can see below the only change in the second study is that the second line has been noted out so the study can backfill.

function main() {
// if (getCurrentBarIndex() != 0) return;
return sma(5, sym("eprem a0"));
}

But as you can also see the two charts are not identical. In your reply you wrote “In real time the comparison is taking into consideration the most current tick intra-bar.” I’m not referring to an intra-bar difference which I understand would be different in real time. The second chart lacks the detail of the first. My question is why? Thanks.

Mike

[mikejhelms]

The pic

The pic was too big so it didn't attach. Here's a smaller version of it.

Mike

[eSignal_JasonK]

Hello Mike,

Thanks for posting the code and images. The results you are seeing are the reality of multiple time frame processing in real time vs. historical bars. For more detailed explanation of this topic, please review this thread.

[mikejhelms]

So is the following summary correct or do I have it backwards? What is actually happening in my “Jason Demo” example in real-time is that what is being used to compute the 5 period simple moving average of the called value is it’s (the called symbol’s) value at the close of the 200 tick emini bar. But if run after hours the called value used in the computation is an average of all the called symbol’s ticks that occurred during the 200 tick emini bar. In other words in real time such an efs plots the average of a value while after hours it plots the average of an average. If that’s correct that would explain the smoothing effect in the after hours chart. Or do I have it backwards and in real time the value used to calculate the study is an average of the called values and the after hours study uses only the final value of the called symbol at the close of the 200 tick emini bar? I’m betting on the first explanation. It’s more intuitively appealing.

Mike

[eSignal_JasonK]

-

Hello Mike,

Please attach a copy of the complete formula you used to create the chart image.

[mikejhelms]

That was the complete formula. There is no more code than the two lines I put in my 02-22-08, 06:21 PM post in this thread which was:

function main() {
if (getCurrentBarIndex() != 0) return;
return sma(5, sym("eprem a0"));
}

When I added it to the chart after hours I noted out the first line to read:

function main() {
//if (getCurrentBarIndex() != 0) return;
return sma(5, sym("eprem a0"));
}

so it would backfill.

Mike

[Dave180]

As another little twist, I would expect to see a slight difference between the two charts because the first tick used in the data might be a different one, ie the sampling point is different (as if say a 5min chart started at one minute past is compared with a normal one), this is especially the case because (based on volume bar experience), eSiganl never seems to download the same number of ticks twice running AND because the servers do NOT seem to carry identical tick data (.05% difference based on a very minute sample). But if you already have the data in memory (same eSignal session) I expect that argument is not relevant.

My intuitive view is that I would expect the average always to be based solely on close() value in each 200tick sample, so the detail should be similar, but maybe not identical because of the above argument (and ignoring the "live" bar at the current moment).

Mike, you might like to try experimenting with ComputeOnClose and with a tick download?

One point though, I thought "EPREM A0" was specifically of value because (unlike $PREM) it is computed at each tick, and it is that time precision that is used by the program trade software, so is using an average of a 200tick sample giving you the information you really want? Not that I've ever used it myself, so please feel free to tell me why that's the wrong view!

[mikejhelms]

Dave:

I agree with you that a bar or two difference is not going to generate the difference seen in these two charts.

Using ComputeOnClose gives me the feeling I think I would get if I drove my car down the freeway with both eyes shut except for a quick glance every five seconds.

I only used eprem to illustrate my point about real-time versus historical charts.

[Dave180]

Hi
The ConC (and tick download) reference was only if you wanted to try to investigate the problem with another "tool", not an ongoing "solution" of some form!

Good luck, I'm intrigued to know what the explanation is.

Dave

[eSignal_JasonK]

Hello Mike,

The main issue here still revolves around historical bar processing vs real time tick-by-tick processing. In addition to this, comparing the 200T interval of two different symbols adds an additional layer complexity to the logic. Because ES has a higher frequency of trades, it will have a higher number of bars for any given range of time compared to EPREM. In real time processing the current value of each symbol can be plotted on a tick-by-tick basis, which is why you see more detail on the real time plot.

When you load the study on historical bars the only data available is the completed bar data, or one closing value per bar. Since EPREM will have bars that cover longer amounts of time per bar due to the lower frequency of trades, the ES chart will plot the close value of the most recent EPREM bar based on the the time stamp of the ES bar. This will result in the same EPREM value being plotted for several bars in a row, which creates the stair-step appearance. This is the only thing that can be plotted while processing the completed historical bar data. This historical plot cannot show the same level of detail that you only see in real time processing because each tick that makes up each historical bar is not processed by EFS while loading on the chart. Hope this helps.