Plotting with getSeries

[mbuta]

Hi,

If a data series is plotted [directly] using getSeries, the plot stays synchronized for all the bars of the external interval.

However, if any processing is applied [ex: CCI/100] the plot is not syncronized anymore [is like plotting with getValue(0)].

Can anybody explain why and what I need to do to have it stay synchronized?

Thank you.

[ACM]

Mihai
When you process a series the formula engine retrieves a value from that series so as to be able to perform the calculations.
This is similar to what is required when processing an array (think in fact of a series as an enhanced array). In that case you would need to retrieve the value (ie element of the array) in order to perform your calculations. In fact myArray/100 will not return anything but myArray[0]/100 will. The same occurrs with a series except that the formula engine retrieves the value for you. And in the same way that processing an element of an array does not return an array if you process a series it does not return a series but a number.
In order to maintain syncronization you would have to perform your calculations in a separate function (or efs) and then call them through efsInternal() or efsExternal() as shown in the example below. This will create the series that the engine requires to be able to maintain full syncronization.
Alex

//this would be in function main()
var myCCI = efsInternal("myCalc",cci(10));

//this is the exyternal function
function myCalc(study){
    return study.getValue(0)/100;
} 

[mbuta]

Hi Alex,

It makes sense what you say and I made them stay synchronized as you said.

a/ It still boggles my mind, why they stay synchronized, because I use an other function to update them only after a certain volume or on NEWBAR.
Note1: I update, manually, last bar [on NEWBAR] and I dont know if [and in what situations] I can rely on EFS2 engine to do the update for me.
Note2: By the way, can EFS2 engine accept colors as data series? I update the value of last bar, but updating the colors is more dificult [they are not part of the ReturnArray].

b/ As you know, I have love/hate for efsInternal. I love it for its conve\nience, I hate it for the time consuming effect [.02-,05ms x every tick x 40-50 data series adds up quick, very quick].

Thanks a lot.

[ACM]

Mihai

b/ As you know, I have love/hate for efsInternal. I love it for its conve\nience, I hate it for the time consuming effect [.02-,05ms x every tick x 40-50 data series adds up quick, very quick].

With all due respect I think you are focusing on insignificant differences. If you consider that on ES (which is one of the most active symbols) you may get 5 ticks per second and you multiply that by 50 series you get a total of 250 ticks per second. Assuming your worst case scenario of an extra 0.05ms per tick that means an extra 12ms ie 12 thousandths of a second per each second counting all 50 series (and assuming also that all 50 update as frequently as ES).
IMO the advantages provided by efsInternal() or efsExternal() far outway this infinitesimal cost.
Just putting things in the proper perspective here.
Alex

Originally posted by mbuta
Hi Alex,

It makes sense what you say and I made them stay synchronized as you said.

a/ It still boggles my mind, why they stay synchronized, because I use an other function to update them only after a certain volume or on NEWBAR.
Note1: I update, manually, last bar [on NEWBAR] and I dont know if [and in what situations] I can rely on EFS2 engine to do the update for me.
Note2: By the way, can EFS2 engine accept colors as data series? I update the value of last bar, but updating the colors is more dificult [they are not part of the ReturnArray].

b/ As you know, I have love/hate for efsInternal. I love it for its conve\nience, I hate it for the time consuming effect [.02-,05ms x every tick x 40-50 data series adds up quick, very quick].
Thanks a lot.

[mbuta]

Alex,

Also with all due respect, the way you put it, it does seem "insignificant", but all I know is that on busy markets, my screen freezes for almost a minute and, by the time it works again, I look at a big move that I could not do anything about it!

This is my prospective.
Mihai

[DionLoy]

Hi Mihai,

Focusing in on just efsInternal() will not solve your problem as Alex has already illustrated that its contribution to CPU usage is insignificant. Significant amounts of profiling on the execution of eSignal has not revealed this to be a heavy consumer of CPU cycles in the scripts that we have tested.

Your script may be written differently however, I would strongly suggest taking advantage of the helpful folks on this board by posting it, so that any inefficiencies in coding can be isolated for your benefit.

Profiling has revealed the slow points in eSignal though, we have plans in place to perhaps run EFSs in parallel on hyper threaded, dual core or dual processor machines. These are being planned for our 8.0 release (date unknown). If these changes work out you should see significant speed increases across the board.

[mbuta]

Hi Dion,

I really don't "focus" on efsInternal [which I would love to be able to use] and you are right, efsInternal is not more CPU consumming than a regular call to function. The diference is that my functions I can control WHEN get executed, but if I make it a data series, gets executed on every tick, which proves [to me at least] to be prohibitiv.
For example, four efsIternal for CCI10/100, CCI20/100, CCI50/100 and CCI100/100, increases the total execution time increades by 60%.

I am sure I have "inefficiencies" and I already know some of them, but I manage to keep the execution time for my script down to .35-1.9ms [depending on what I plot] and the average for my standard setup is .75-.8ms. is ok for now, but I still have stuff to put in. It was my experience that if the execution time is over 2ms, I run into trouble with active markets, like SMH, QQQQ, Intel, etc.

Since you guys introduced EFS2, I am trying to find a combination that gives me the flexibility of EFS2 without performance penalization. I keep trying and when/if I get stuck, I wil ask the help of the nice and competent people on this board. But I have to try everything I can first.

If you are taking suggestions for future revisions, I can make a few:
a/ Introduce an object "study" and allow operands when data series are declared.
Ex: var stXYZ = new Study (sma(3) - sma(20));
This way no efsInternal is needed and, maybe, you can treat it as a regular [builtin] study, such that does not appear on Performance Monitor anymore.
b/ Make available to us NEWBAR state for external timeframes.

Thank you and best regards,
Mihai

[ACM]

Mihai

b/ Make available to us NEWBAR state for external timeframes.

As I believe I indicated to you in a prior post this is already available through getBarStateInterval("interval") or getBarStateSymbol("symbol" or "symbol,interval")
Alex

[DionLoy]

Mihai, a new Study(...). will have the same performance impact as an efsInternal().

efsInternal is NOT doing anything extra that is not ABSOLUTELY necessary for correct calculations.

efsInternal is essentially a built-in study.

Your 'performance penalization' is not a valid argument ... Your old EFS1 code is NOT equivalent functionally to the EFS2 code that you have written.

Your EFS2 code is doing many more calculations and synchronizations that were NOT being done in your EFS1 code.

Again, you are comparing apples to oranges.

We are working on improving the speed overall (as improvements can always be made to any system), but unless you can provide to us EFS1 code that performs the SAME synchronization as EFS2 and performs faster, this discussion is a waste of ALL of our time.

[mbuta]

Alex,

Yes, I remember you mentioned something like that, but could not find them in the Docs and they don't appear on f(x), so did not know how to use.

Dion,
If efsInternal is "essentially a builtin study", why does it appear as separate line in Perfomance Monitor? Buitin studies don't.

Also, the new Study idea was to allow operands, between studies, or other processing, without having to write a function for that, then call it with efsInternal.
I know that the majority of what I would like to declare as custom data series fall in this category.

Mihai

[DionLoy]

built-in studies were restricted from appearing in the performance monitor to avoid clutter.

new Study(sma(2) - sma(3)) is not possible in JavaScript, as the language laws indicate that sma(2) - sma(3) would be evaluated in place, before it gets into the Study constructor.

One could devise a syntax like:

new Study("sma(2) - sma(3)"), which internally would translate into:

efsInternal("_generatedFunction")

function _generatedFunction() {
return sma(2) - sma(3);
}

however that syntax, while saving you some screen real estate, eliminates the possibility for the syntax checker to check the syntax within the " " quotes.

[mbuta]

Dion,

I see you got the idea. I am not a software person to know the details you give, but I know I wished I had such a feature available.