My problem or eSignals - multi-interval series objects

[gspiker]

Attached is the version of the test efs that prints the data. It is kind of a crude mechanism, but it works.

Run as is for RT...when you go to load the second chart either edit the current file, or create a new one with the conditionals changed to reflect the ones commented out ie:

When running in RT:
if ( nBarState == BARSTATE_NEWBAR && getCurrentBarIndex() == 0 ) {
//if ( nBarState == BARSTATE_NEWBAR ) {

When running in historical:
// if ( nBarState == BARSTATE_NEWBAR && getCurrentBarIndex() == 0 ) {
if ( nBarState == BARSTATE_NEWBAR ) {

This will generate much more data than you need for the historical data, and the better way to do this would have been to check current date against chart date so the same code can be used in both cases...but I wanted to crank this out and can never remember the date commands.

Again, any help or suggestions would be appreciated.

Garth

[Guest]

Hi Garth,

I jumped into this thread and worked on your posted efs a bit, I figured neither you or Jason would mind.

I started by updating the trace function to a version that captures the output from any efs2 object created with efsInternal() that is accessing the trace function. I didn't test it thoroughly since the extra functionality isn't really required, but it seemed to work well for this example and helped me understand things better.

I structured the output a little differently too and put index numbers in the efs2 time methods as well.

Hope it all makes sense. btw, I ran this with the Beta of 10.2, version 10.2.1355.1095 9/16/2008.

[gspiker]

Hi Steve,

Thanks for jumping in.

I downloaded the EFS and looked it over...I wasn't sure from your post exactly what you were doing but the code made it clear.

I think I'm going to take what you did and modify it a bit more to create a CSV that I can import into excel and do some analysis on.

Did you get a chance to run this in RT? Did you see anything interesting?

Thanks!

Garth

[Guest]

Hi Garth,

Your welcome as always. It was getting a bit late and my ability to explain things had gone well past the point of diminishing returns. Good to hear the efs helped explain things, I was hoping as much.

A couple things.

I have not run the efs live yet, I was looking for something from you that described how you were saving the data, and last night was the first chance I had to look at it.

The behavior of the file output using the trace function was interesting. While I know that when an efs2 object is instantiated, the existing objects and variables are copied, the behavior was different than I expected. While everything worked as it should have (as coded), I had to structure the trace output to figure things out for myself. The structure of the trace output statements helped me look at how the efs engine sequences things when creating an efs2 object with efsInternal (what happens first, second, third, etc ).

Having said that, the order and structure of the conditionals was deliberate and would recommend you follow something similar that indicates which conditional fired for each line saved to the file. If the data saved is normal, the extra information can be ignored. However, if there are some abnormalities, the additional info may provide insight.

If you are going to be performing sorting or comparison with date information, I recommend using the rawtime() method here http://kb.esignalcentral.com/article...ticle=2360&p=4

In addition to any date information that you are already recording. If have found rawtime very helpful to index data in the past, especially handy when processing in excel.

hour() and minute() are some other efs2 methods you may want to consider as well.

I'll run this next week and look for issues on my end.

[gspiker]

OK, I ran the modified script in RT today, and then ran it again using historical data.

There does appear to be a mismatch between prices and when it thinks the hour ends. However even odder it appears that the RT results don't always match what the chart says it should be.

I'm attaching the associated CSV files (trimmed down to reduce size) and the EFS script.

This is the RT csv results


Thanks,

Garth

[gspiker]

Historical results

[gspiker]

Data export of 30 minute chart

[gspiker]

and the EFS...sorry I didn't rename it from Steve's original.

[clearpicks]

Garth,

I did not study your posts and scripts in details, however I think it might be related to the issue I discussed in this thread http://forum.esignalcentral.com/show...threadid=26136

- Clearpicks

[gspiker]

clearpicks,

Thanks for the reply. In my case I'm using the same symbol, but a different interval. Do I still need to use the same technique?

I'm not sure how eSignal delivers data, but I would assume that there would be only one data stream per symbol and therefore it isn't required. Am I incorrect on this assumption?

Thanks,

Garth

[clearpicks]

I think it should be only one data stream for the same symbol. But in some build, (10.1?), daily symbol would add one redundant data stream into the efs running on intraday charts of the same primary symbol.

Anyway, you may try to create two additional data series
xHour = hour ( sym ( sSymbol ) );
xMinute = minute ( sym ( sSymbol ) );
and also use

getValueAbsolute("Hour", 0, -1, sSymbol);
getValueAbsolute("Minute", 0, -1, sSymbol);
getValueAbsolute("Hour", 0, -1, getSymbol()+","+getInterval());
getValueAbsolute("Minute", 0, -1, getSymbol()+","+getInterval());

to try to identify any possible misalignment as I did in some of my other posts.

[gspiker]

Just an update.

Well, after three+ weeks of running with that latest version of 10.1 I have only seen the problem twice. That is a major improvement, but I'm not sure if I'm happy about that or not...it will make it that much harder to debug the problem.

I'm going to download the latest version of eSignal and see what happens. I hope it either fixes the problem entirely or makes it far worse. There is nothing worse the intermittently bad data.

Thanks again for everyone's help on this.