getSeries()

[Dave180]

[Not the two parameter array-access overload]
Given, in the KB:

//use getSeries() to ensure that the actual series is being returned, rather than the values 
return new Array( getSeries( myStudy1 ), getSeries( myStudy2 ) ); 

where, and similarly for myStudy2

myStudy1 = ema( 20, inv(30) ); 

and

Any of the Built-in Study Functions or Series Functions can be used to create a Series Object.
xSeriesObj = SeriesFunction( [ parameters ] )
Where: xSeriesObj is a user-defined variable and SeriesFunction is one of the Built-in Study or Series functions.
The parameters specified would correspond to the parameters for the specific series function if applicable.

there seems to be a contradiction. ema() is one of the built-in studies, so it returns a series, so getSeries() would seem to be redundant.
But experimentation (with volume() rather than ema()) shows that getSeries() does make a difference.
In the EFS Custom folder there is a customVolume study, it does a

return volume(sym(vSymbol)); 

I have been using this with a five minute interval on a one minute chart. See how it retrospectively changes the volume for EACH of the one minute bars in the "current" five minute bar as the five minute bar is built.
The performance monitor shows that this routine is very inefficient, so I recoded it using some stored variables.

If you create a variable and initiate it with the series and then return the variable the display changes. Why should that be? Infact various odd things happen, with historic and live bars behaving differently

var xVolume = null; // scope outside main()
...
// init once

mxVolume = volume(sym(vSymbol)); // where vSymbol is like "IBM,5"
...
// Each tick
var fVol = mxVolume .getValue(0);
...
// alternative returns
return volume(sym(vSymbol)); // 1. original version, see that in current bars the group of one minute bars
                          // in the current five minute bar all change together (ie not just the current one minute bar). 
                          // How does that actually work, afterall, we are returnig data for the chart's current one minute bar?
return mxVolume;  // 2. surely this returns the series just like the first return line. But it doesn't, instead see garbage data, why?
return getSeries(mxVolume);  // 3. This displays just like the first return line. Why is getSeries() needed?
return fVol; // 4. now we see that for curernt (not historic) bars, each one minute bar in the same five mnute group is different, 
                          //and grows, this at least makes sense, but you realise why the first return is so neat. 

See the attached chart, it shows only bars drawn after chart was loaded, not historical bars
Queries are:
Why does returning a variable that has had a series assigned to it not work just like returning the series function directly?
What does getSeries() do to fix this?
What is a simple explanation of when a longer time frame series is returned, all of the bars on the chart in the longer time frame are updated (not just current bar chart)?
But if you apply getSeries() to the variable it works again.
So what is it about needing getSeries() if the series is stored in a variable?

[Guest]

Dave,

Reading your post makes my head hurt, too many questions and not enough time to answer them. FWIW, I had previously tried to explain the different nuances in this thread.

I believe my posts in the referenced thread lines up pretty well with the majority of your questions.

Check them out and let me know.

Originally posted by Dave180
[Not the two parameter array-access overload]
Given, in the KB:

//use getSeries() to ensure that the actual series is being returned, rather than the values 
return new Array( getSeries( myStudy1 ), getSeries( myStudy2 ) ); 

where, and similarly for myStudy2

myStudy1 = ema( 20, inv(30) ); 

and



there seems to be a contradiction. ema() is one of the built-in studies, so it returns a series, so getSeries() would seem to be redundant.
But experimentation (with volume() rather than ema()) shows that getSeries() does make a difference.
In the EFS Custom folder there is a customVolume study, it does a

return volume(sym(vSymbol)); 

I have been using this with a five minute interval on a one minute chart. See how it retrospectively changes the volume for EACH of the one minute bars in the "current" five minute bar as the five minute bar is built.
The performance monitor shows that this routine is very inefficient, so I recoded it using some stored variables.

If you create a variable and initiate it with the series and then return the variable the display changes. Why should that be? Infact various odd things happen, with historic and live bars behaving differently

var xVolume = null; // scope outside main()
...
// init once

mxVolume = volume(sym(vSymbol)); // where vSymbol is like "IBM,5"
...
// Each tick
var fVol = mxVolume .getValue(0);
...
// alternative returns
return volume(sym(vSymbol)); // 1. original version, see that in current bars the group of one minute bars
                          // in the current five minute bar all change together (ie not just the current one minute bar). 
                          // How does that actually work, afterall, we are returnig data for the chart's current one minute bar?
return mxVolume;  // 2. surely this returns the series just like the first return line. But it doesn't, instead see garbage data, why?
return getSeries(mxVolume);  // 3. This displays just like the first return line. Why is getSeries() needed?
return fVol; // 4. now we see that for curernt (not historic) bars, each one minute bar in the same five mnute group is different, 
                          //and grows, this at least makes sense, but you realise why the first return is so neat. 

See the attached chart, it shows only bars drawn after chart was loaded, not historical bars
Queries are:
Why does returning a variable that has had a series assigned to it not work just like returning the series function directly?
What does getSeries() do to fix this?
What is a simple explanation of when a longer time frame series is returned, all of the bars on the chart in the longer time frame are updated (not just current bar chart)?
But if you apply getSeries() to the variable it works again.
So what is it about needing getSeries() if the series is stored in a variable?

[Dave180]

Hi Steve
Although I remembered you had written that article either me or my search for "getSeries()" must have missed it.
Your article was and is of inetrest to me, thanks, esp re "series" vs "Series".
However, what you say seems to be at odds with what I described as actual behaviour

Picking up where I left off previously, once you have a global variable that references the internal series (representing the Series object output), you no longer have to execute the getSeries() function every tick to see changes in that object. This is because the internal object has been passed by reference and updates automatically.

My example shows that when you have a global variable you still have to use getSeries(). Odd I agree, but the 2nd indicator pane in the chart example shows what happens when you don't use getSeries (in 10.2 at least).
Hurts my head too! If eSignal could provide decent documentation we would both have a more productive life.

[Guest]

Hi Dave,

I honestly feel that between the KnowledgeBase and the forum content (examples, answers to questions and in depth explanations) the available documentation is quite adequate. After all, I learned how things work using some of the same learning tools as you have. I had an epiphany the other day when I realized that I have been hesitant to jump in and answer some of your posts since you oftentimes post follow-ups complaining about eSignal documentation or other related areas where I am in disagreement with your positions. I believe my feelings are attributable to human nature, I simply do not feel comfortable or enjoy being part of negative threads or likewise trying to address issues that are completely out of my control. However, I do not have a problem helping you work through issues in a constructive manner. In fact I rather enjoy it since I almost always come away from constructive exchanges learning something new.

As far as your examples, they are behaving exactly how I would expect them to and as documented elsewhere, most notably in previous explanatory threads that Alex published. If you look in my signature, there are several links that go over the different EFS2 techniques.

As far as being inconsistent with the information in the thread I referenced, either you misinterpreted what I said, or I misspoke, as none of the code seems to match up with my recommendations. If you want, post a working efs using the most efficient techniques that you have come up with. I will see if I can improve on it and provide any necessary explanations.

FWIW, these efficiency tweaks and others I have published over the years are simple JavaScript techniques for improving efficiency. They are all over the internet and I documented the best links I found in my fileshare. I have learned how to apply these to eSignal objects (which are themselves relatively straightforward JavaScript objects) over the years, for the most part by researching and working through them myself. Those I could not figure out were either answered by others on the forum or were figured out while assisting others on this forum.

I hope you find this helpful.

Originally posted by Dave180
Hi Steve
Although I remembered you had written that article either me or my search for "getSeries()" must have missed it.
Your article was and is of inetrest to me, thanks, esp re "series" vs "Series".
However, what you say seems to be at odds with what I described as actual behaviour


My example shows that when you have a global variable you still have to use getSeries(). Odd I agree, but the 2nd indicator pane in the chart example shows what happens when you don't use getSeries (in 10.2 at least).
Hurts my head too! If eSignal could provide decent documentation we would both have a more productive life.

[Dave180]

Thanks for your reply Steve, I think we have a fundamental difference of attitude as to how a serious software publisher should document and "ease" the use of their tools. I believe in comprehensive documentation with clear cross-referencing and useful (explanatory and comparative) examples. I appreciate that many topics of interest will get covered in the forum, but ultimately eSignal should see this as an almost free resource of ideas and solutions and common misunderstandings that should be continually included in their documentation to save new and old users from repeating mistakes and quickly achieving their goals (which is not meant to be programming for its own sake) - I don't think I should need to continually wade through endless threads looking for the gold nuggest that you and others provide to make up for these deficiencies. I haven't seen much in the way of improved documentation since I started.

As for this specifc issue, this (one) is not about effciency in itself (although it was discovered when improving it).

Simply put, it is beyond me why assigning the series returned from an efs function (volume()) to a variable and then returning that variable should behave differently to returning the function directly. I find that type of obscure behaviour peculiar, to say the least, and I really don't recall any document that explains it but would be grateful for a link for future reference.

As for effciency, thank you for your various inputs. But what I find most odd is that the sample efs scripts (such as the one I was working on) that come with eSignal seem to demonstrate the "clean but slow" approach to using efs (eg continual avoidable per-tick parameter validity checks and string comparisons - the sort of coding that a computer science afficonado with no respect for actual cpu cycle resources does) rather than demonstrate the effciency needed in todays high tick-volume markets. Time for an improvement I think, it sets the wrong example.

Dave