Stochastic in different timeframe

[shaeffer]

I'm half way thru Jay's EFS instruction videos, so I'm hoping someone will know of an existing EFS that is close to what I want.

I want to set the background color of a 15 minute chart based on the direction of the 60 minute stochastic fast line. If the stos60 fast line is rising, then I'd want a green background, which would then change to red when stos60 started falling.

Anyone know of an existing EFS that is close to this?

Thanks
shaeffer

[ACM]

shaeffer
You could use the customStoch.efs that is provided in the EFS 2 Custom folder of Formulas as the base for your script.
Just add the required conditions before the return statement ie

if(xStochK.getValue(0)>xStochK.getValue(-1){
    setChartBG(Color.your_color);
}else{
    setChartBG(Color.your_default_color); 

The solution above will paint the whole chart's background when the condition is true and revert back to the default when it is not. If instead you want to paint the bar's background then you would use

if(xStochK.getValue(0)>xStochK.getValue(-1){
    setChartBG(Color.your_color);
} 

In this case though you need to understand that while the bar's background may be painted in real time (because the condition is true at that moment) if you then reload the efs and the condition is no longer true the background will no longer be painted even if during any moment within the external time frame the condition was true.
If you want to maintain the color of the background fully synchronized to the external interval you will need to implement a solution similar to the one provided in this post
Alex

[shaeffer]

Thank you Alex,

Over the weekend I took an older EFS and modified it as attached.
1. I think the rawtime command (line 30), prevents multiple sound alerts (from lines 34 and 40)?

2. I do not know what those getBarState commands do (lines 48, 52, 57,62). Can they be deleted?

I know that some of the preMain commands are not needed, but I left them in for temporary plotting of the stochastic curve during testing.

Yes, the BG color does change a few times before the 60 minute interval is complete, so some premature signals can and do occur. But my thought is that the 60 minute stochastic that is trying to turn up mid interval, will likely do so if the 15 minute stochastic is also turning up within that 60 minute interval. I'll see if this results in earlier valid signals, or too many false signals. I'll read that link re synchronized external interval, and see if that is something I should consider.

Meanwhile, if anyone cares to look over this EFS for questions 1 and 2 above, or for any other mistakes I've made, it would be much appreciated.

Thanks
shaeffer

[ACM]

shaeffer
The if(getValue("rawtime",0) != nLastRawTime) conditional statement in line 30 is another way of checking for a new bar ie it is the same as writing if(getBarState()==BARSTATE_NEWBAR).
So while it does prevent multiple sound alerts it also means that the alerts will be triggered only if the conditions you enclosed in the if(getValue("rawtime",0) != nLastRawTime) statement occurr on the first tick of a new bar which I don't think is what you are trying to accomplish.
What you would need to do is first create a global variable called for example bFlag and set it initially to false.
Then at the beginning of function main you include the following code which will reset the flag at every new bar of the chart interval

if(getBarState()==BARSTATE_NEWBAR){
    bFlag = false;
} 

If instead you want to reset the flag at every new bar of the external interval then you would write

if(getBarStateInterval("60")==BARSTATE_NEWBAR){//replace "60" with your external interval
    bFlag = false;
} 

Once you have added either of the above you set your original conditions as follows

//Cross Up thru 20
    if(bFlag==false){//check for bFlag to be false thereby preventing multiple intrabar alerts
        if(stoF.getValue(-1) < Lower && stoF > Lower){//if the condition is true
            Alert.playSound("ChatInvt.wav");//execute this
            Alert.addToList(getSymbol(),"Stos60 Up",Color.black,Color.green);//execute this
            bFlag = true;//set bFlag to true
// Cross Down thru 80   
        }else if(stoF.getValue(-1) > Upper && stoF < Upper){
            Alert.playSound("hoot1.wav");
            Alert.addToList(getSymbol(),"Stos60 Dn  ",Color.black,Color.maroon);
            bFlag = true
        }
    } 

This way if the Stochastic conditions were to return true intrabar the alerts would still trigger only once
As to your second question from what I can see the BARSTATE_ALLBARS condition is not required
Alex

[shaeffer]

Hi Alex,

In the previous EFS, I replaced the rawtime command with the BarState command (per your first sentence), and later tried the two variations you suggested. But I'm not sure exactly what these variations should be achieving.

Considering only the first alert condition (Fast Line cross up thru 20) let's say the following happened:

1. At 9:40 the alert condition occurred,
2. At 10:05 it fell back below 20
3. At 10:35 the alert condition occurred
4 At 11:40 it fell below 20

With the EFS as it is attached now (no flags) should I get alerts at 9:40 and 10:35? As is (without the flags), does this become much more CPU intensive?

If instead I used the commands in your first PHP (with chart interval of 15 minutes), should I get alerts at the first tick after 9:45 and 10:45?

If I used the commands in your 2nd PHP (with external (EFS indicator) interval of 60 minutes), would I get just one alert at the first tick after 11:30?

Thanks
shaeffer

P.S. When writing forum notes, when you open a PHP can you paste into the PHP, or only directly type? Similarly, to create multiple quotes, can you paste or only type.

[shaeffer]

It seems if one uses Preview Reply, and then Submit Reply, the attachment gets lost?

[Guest]

Hi shaeffer,

That is correct. When replying to a post, any file that you have placed in the "Attach file:" block disappears when you preview your reply. What I do is highlight it and copy it when I preview the reply, then paste it back in again when I am ready to post.

[ACM]

shaeffer

In the previous EFS, I replaced the rawtime command with the BarState command (per your first sentence)...

I actually misread your original script and thought you were resetting nLastRawTime at every bar instead of when an alert is triggered. This is why I suggested to use a flag which is in effect similar to what you were already doing.
As is the current script will trigger an alert only if the condition is true on the first tick of a new bar so if this is not what you want you can either restore your original rawtime condition or implement the solution I suggested in my prior reply.

...and later tried the two variations you suggested. But I'm not sure exactly what these variations should be achieving

The two conditions if(getBarState()...) and if(getBarStateInterval("60")...) will reset the flag differently. The first one will reset the flag at every new bar of the chart interval (ie every 15 minutes if that is the interval you are plotting) while the second will reset the flag at every new bar of the external interval (in the example every 60 minutes). In the first case an alert will be triggered once if at any time during the 15 minute interval the condition returns true. In the second instead an alert will be triggered once if at any time during the 60 minute interval the condition returns true
Alex

[shaeffer]

Hi Alex,

I've changed the EFS (attached) back to using the previous rawtime condition, but I'm still not sure what this actually does within the script. So please bear with me while I break this into baby steps.

The definition for rawtime() says:
Returns the rawtime (number of seconds elapsed since 01/01/1970) at the specified bar index.
I understand the first part of that, but what does "at the specified bar index" mean? Does that mean at the first second of the next chart interval (or other interval if the 'inv()' parameter is used)?

If that is correct and I use this EFS in a 15 minute chart, then getValue("rawtime",0) is a fixed value for the entire 15 minute interval, and it then increments by (15x60 = ) 900 seconds at the first second of the next interval?

And if that is right, then the alert should sound the second a line 32 or 37 condition is true, but not again until either condition is true in that next interval?

Is that what you've been telling me?

The first time line 30 is read, is nLastRawTime assumed to = 0? Should line 5 specify that, ideally?

(Your patience is much appreciated)
Regards
shaeffer

[ACM]

shaeffer

...but I'm still not sure what this actually does within the script

The if(getValue("rawtime",0) != nLastRawTime) condition checks if the current bar time - which in your script is espressed as rawtime ie the number of seconds elapsed since 00:00 of 1/1/1970 - is different from the value of the variable nLastRawTime which represents the bar time when an alert was last triggered
The condition then returns true or false.

A) If the condition returns true (ie nLastRawTime is different from the current bar time) then the efs proceeds to evaluate the condition for the Stochastic study which also returns true or false
--> 1) If the Stochastic condition returns false the efs does nothing
--> 2) If the Stochastic condition returns true then the efs triggers the alert and assigns to the variable nLastRawTime the current bar time. At this point nLastRawTime will have the same value as the current bar time (until a new bar forms)

B) If instead the condition returns false (ie nLastRawTime is equal to the current bar time because an alert was triggered on the current bar) then the efs will not evaluate the Stochastic condition hence it will also not trigger any further alerts for the duration of that bar.
Once a new bar starts nLastRawTime will once again be different from the current bar time and the efs will evaluate the Stochastic condition again.

...I understand the first part of that, but what does "at the specified bar index" mean?

It means that you can specify for which bar you want the rawtime. For example rawtime(0) is the current bar's time, rawtime(-1) is the prior bar's time etc. Note that rawtime(0) is the EFS2 syntax whereas getValue("rawtime",0) is the EFS1 syntax.
Alex

[shaeffer]

Hi Alex,

I need some real times to be sure I understand this.

Let's say at 9:30 when the market opens, neither of the conditions in lines 32 or 37 are true. I assume nLastRawTime has no value (null) at 9:30 because the program has never reached lines 35 or 40 yet to assign it a value?

So line 30 is read at 9:30, and because nLastRawTime is null, then getValue ("rawtime",0) will be different, hence lines 23 and 37 are evaluated. But neither of those conditions are true yet, so nLastRawTime still has no value.

Do these statements get read and evaluated in this EFS for every single price tick, or after every single second?

Let's say that finally at 9:52, (part way into the second 15 minute bar of the day), condition 32 is true, so line 35 assigns nLastRawTime a value. Even though the true condition occurred at 9:52, will getValue("rawtime",0) assign to nLastRawTime the value associated with real time 9:45:01 (the first second at the start of the second bar)? And if so, is that why the alert will never sound a second time within any one bar - because getValue("rawtime",0) will be the same throughout the duration of that bar?

In other words, does 'bar time' in your answer mean the equivalent of real time 9:45:01 in the above example?

Should I change this to EFS2 code - would that reduce CPU load?

Thanks again.
shaeffer

[ACM]

shaeffer

Do these statements get read and evaluated in this EFS for every single price tick, or after every single second?

The efs evaluates the conditions on every tick (unless you have setComputeOnClose() in preMain or have enclosed all your conditions inside a BARSTATE_NEWBAR conditional statement)

Even though the true condition occurred at 9:52, will getValue("rawtime",0) assign to nLastRawTime the value associated with real time 9:45:01 (the first second at the start of the second bar)?

When the alert gets triggered the value that is assigned to nLastRawTime is "rawtime" which is the bar time ie 09:30:00, 09:45:00, 10:00:00 etc on a 15 minute chart. In eSignal the bars get time stamped with the time of the beginning of an interval.

And if so, is that why the alert will never sound a second time within any one bar - because getValue("rawtime",0) will be the same throughout the duration of that bar?

That is correct. "rawtime" will be the same for the whole duration of a bar

In other words, does 'bar time' in your answer mean the equivalent of real time 9:45:01 in the above example?

No bar time is the start time of every bar whereas real time is the computer time. In minute based bars the seconds are always 00

Should I change this to EFS2 code - would that reduce CPU load?

In this case it would make no difference at all.
Alex

[shaeffer]

Hi Alex,

Thanks to your help, I believe I now understand what is happening within the rawtime if statement group.
-------------------------------------------
Following that rawtime if statement group are four 'if/else if ' statements. As I understand it, using the 'else if' statements (as opposed to just 'if' statements) reduces CPU loading since as soon as one statement is true, no further processing of the other statements occurs - is that correct? Otherwise these statements would also get evaluated on every single tick?

Let's say the first condition (the 'if' statement) becomes true at time (tick) 'x', and remains true for the following 20 ticks. So at tick x, the background (Bg) color is changed to pink. Then at tick x+1, is the Bg color repainted pink or does the program know if was already pink from the previous tick?

Best Regards
shaeffer

[ACM]

shaeffer

As I understand it, using the 'else if' statements......as soon as one statement is true, no further processing of the other statements occurs - is that correct?

That is correct.

Then at tick x+1, is the Bg color repainted pink or does the program know if was already pink from the previous tick?

The conditions are re-evaluated at every iteration of the efs (ie at every tick) and the background is repainted accordingly
Alex

[shaeffer]

Originally posted by Alexis C. Montenegro
The conditions are re-evaluated at every iteration of the efs (ie at every tick) and the background is repainted accordingly
Alex

Thanks for the reply Alex,

In my usual layout, I have 47 charts that use this (or similar EFS's) to change background colors. So these background colors getting repainted at every tick seems like a huge amount of CPU/graphics effort. Would you agree, or is all this repainting a relatively minor effort for a 2GHz P4 computer with 2GB ram? Perhaps doing the stochastics calcs in those 'if/else if' statements is much more CPU intensive than repainting each time?

I'm wondering if its worth adding flags to this EFS so that if the same 'if/else if' statement is true for say 50 consecutive ticks, the same background color is not repainted 50 times.

Why I keep bringing up CPU useage is that I can not use eSignal Time & Sales. Only during slow market times can it keep up. Most of the time it is very ****y, and lags behind the sales I see in IB. Yet strangely, I have two 3rd party software packages that use eSignal data, and the T&S in both of those is smoother and up to date. So I'm thinking I may have loaded up my layout with inefficient efs's, that may be slowing down eSignal processing. That's why my focus on understanding and fine tuning my efs's.

Incidentally, in the above 47 charts plus another 22 charts, (in six monitors) I change the Bar Bg color in studies to denote certain conditions. Originally I changed the Bg color of all the bars in the study when the condition occurred, and my computer was verrrry slow. I then added a loop to those efs's so the Bg color of only the last 10 bars of the study would change, and that seemed to improve things. That's why I'm thinking that reducing the repaints of ChartBg color might be a performance improvement? Do you think it would help?

Regards
shaeffer