Intermittent intrabar meeting of an interbar criteria

[mikejhelms]

Hello all. Here's a simple example of a problem I have encountered with an intermittent intrabar meeting of an indicator's interbar criteria and what seems to me the inadequacy of using Computeonclose or BarState to solve this problem. Suppose I wanted to paint the price bars green if the current tic is higher than the previous bar's high (criteria #1), and continue to paint them green until the current tic is lower than the previous bar's low (criteria #2), at which point they would then be painted red. There would be no problem with this if the indicator was set to computeonclose. But what if the indicator was set to update on every tic and the criteria was met and then not met within the same bar?

For example, using one minute bars suppose bar #1 is green and bars #2 through #4 are also green because none of them have met the switching criteria. Then at 15 seconds into bar #5 the switching criteria is met, the default color is changed to red and bar #5 is now painted red. But at 30 seconds into bar #5 the current tic no longer meets the switching criteria, that is it is no longer lower than the previous low, BUT NOR IS IT HIGHER THAN THE PREVIOUS HIGH, so it has not met the criteria to switch the default color back to green. Assumming the price does not change from its thirty second price, then at the close of the 5th bar althougth the final tic is not lower than the previous low, the color of the bar has switched from green to red.

You may suggest I use BarState to identify a new bar and do a Computeonclose to reset the previous bar to its proper color. Sounds good ... but if instead of a one minute bar suppose we are dealing with a ten minute bar and, as I noted above the intrabar criteria match and then "not match" took place thirty seconds into the bar. In that case, for the remaining nine minutes and thirty seconds, that is until the next ten minute bar appears, a bar that should be painted green is painted red. And as Mel Brooks might say, "That ain't good."

So if the criteria is met intrabar, I'd like the color to switch. But if within the same bar conditions change and the crieria is no longer met then I would like it to switch back to the color of the previous bar. Any suggestions on how this could be done? Many thanks.

[ACM]

mikejhelms
Assuming I understood what you are trying to accomplish the issue is not one of inadequacy of setComputeOnClose() or BARSTATE_NEWBAR. Those functions will do what they are supposed to depending on the logic being used. Here is what you would need to do.
The first step is to create two global variables which will hold the current bar's color (Color0) and the prior bar's color (Color1). Set them initially to black (or any other color of your choice).



Then at the beginning of function main inside a BARSTATE_NEWBAR condition you transfer the value of Color0 to Color1 as in the following example. In doing this you define what the color of the prior bar is. This step needs to be performed prior to computing the current value of Color0.



At this point you can write the conditions that will determine what Color0 will be and you assign the appropriate color to the variable. Failing those conditions you will assign to Color0 the value of Color1 (ie the color at the prior bar). Once that is done you add the setPriceBarColor() command using Color0 as the parameter (see image below)
Hope this helps
Alex

[mikejhelms]

Alex, that approach works very well. Thanks for your suggestion.

Mike

[mikejhelms]

One step further?

Alexis, can you help me take it one step further by defining conditions for two types of green and two types of red? As the program you suggested below now stands: If the previous price bar, PB(-1), has been painted green and the current price bar, PB(0), does not meet the condition to turn red then PB(0) will remain the color of the previous bar, in this case green.

What I would like to add is, if PB(-1) was green and PB(0) once again meets the green conditon, that is close(0)>high(-1) && volume(0)>volume(-1), then I would like it to be painted DARK green. If the following price bar, PB(+1), meets neither the red or green conditions, it would revert to regular green. In other words, within a set of for example ten consecutive green bars, I would like the program to paint DARK green any single bar that would have already been painted regular green because of the previous bar, but has once again met the green criteria. The following bars would return to regurlar green until the red criteria is met at which point they would be painted red. The same would be true in a red series. That is, if within a series of red bars a single bar should appear that once again fulfills the red criteria, that is close(0)<low(-1) && volume(0)>volume(-1), that single bar should be painted DARK red, with the rest of the series returning to regular red.

I realize this sounds rather tedious but I would appreciate your help because I have found bars meeting the green and red criteria to be excellant indicators for gauging the strenght of a price movement and for identifying both acceleration and exhaustion bars. I know this is doable but I can't seem to get it to work. Would you help by bringing your wisdom to bear on the problem?

Many thanks,
Mike

[eSignal_JasonK]

Hello Mike,

The simplest solution would be to add two additional if() statements to your color conditions where you would check the relationships of the previous bar as well. These if() statements would be nested inside the initial if() statement. For example,

if (close(0) > high(-1)) {
    Color0 = Color.lime;
    if (close(-1) > high(-2)) {
        Color0 = Color.green;    
    }
} else if (close(0) < low(-1)) {
    Color0 = Color.red;
    if (close(-1) < low(-2)) {
        Color0 = Color.maroon;    
    }  
} else {
    Color0 = Color1;
}
setPriceBarColor(Color0); 

[mikejhelms]

Thanks for looking at the problem

Jason, thanks for the try but that wouldn't work because all the green bars don't meet the "change to green criteria" and all the red bars don't meet the "change to red criteria." They just go green, for example, and stay that way until the "change to red" criteria is met and then they go red. So referencing those intermediate but non-criteria meeting bars wouldn't work. It occurred to me though that a simple way to identify the bars I referred to would simply be to draw an arrow above or below the appropriate bar.

Although I've never used the drawShape function before, it worked on the first try. Like Edison I am suspicious of anything that works on the first attempt, but hey ... I say take it when life throws you an easy one for a change.


Mike

[Doji3333]

Possible Solution..

I'm not sure I have your logic correct, but this should be much closer to what you want to accomplish. It just takes a bit more logic to handle everything..

B

See the above post for the corrected version...

[Doji3333]

Oops..

Found a copy/paste error in my code.. Try this one..

B

[mikejhelms]

Thanks and a small but ...

Brad, that's a hell of a piece of work. I'm amazed you put in the significant amount of time it must have required to write it. Thank you.

And it works ... in real-time. Unfortunately it does not work consistantly on historical data. That is, if you put up a one minute chart of today's (1-17-06) intraday emini (es #f) data and then add your study to the chart, you'll notice that although it colors most of the bars correctly, there are bars whose color should have been switched but were not. Some bars that should have switched from lime to green, did not. For example, 11:30 & 11:37. And some that should have switched from red to maroon did not. For example, 12:28 & 12:56. Luckily the program I mentioned in my post to Jason, the one using the drawShape Arrow, does work on historical data so using your program on realtime data and mine on historical data covers all the bases for me. Thank you again for your effort.

Mike

[mikejhelms]

a real-time bump

Brad, again I appreciate the time you put in on Helms.efs but I'm going to have to retract the statement I made in my previous post that it works in real-time. If a bar is green or lime and the switching to maroon criteria is met, close()<low(-1) && volume()>volume(-1), then it does switch to maroon as it should. But if 15 seconds later, within the same one minute bar, the price rises a bit so that close()>low(-1), that is the switching criteria is no longer met, then the bar does not switch back to lime or green. It stays red. If you're interested in fixing this you might want to check out Alexis' post on how he approached this problem.

[ACM]

Mike
To correctly paint the bars with the additional conditions you provided you need to modify my original code as follows. First edit the getBarState() conditional statement as shown below



Then modify the primary condition as shown below (BTW this is along the same lines as suggested by Jason in his reply to you)



Once you implement these changes the script will work correctly both on historical data and in real time.
FWIW the problems you are seeing are caused by an incorrect usage of the setBar() command which cannot be used to paint price bars since these cannot be painted retroactively.
Alex

Originally posted by mikejhelms
Brad, again I appreciate the time you put in on Helms.efs but I'm going to have to retract the statement I made in my previous post that it works in real-time. If a bar is green or lime and the switching to maroon criteria is met close()<low(-1) && volume()>volume(-1) then it does switch to maroon as it should. But if 15 seconds later, within the same one minute bar, the price rises a bit so that close()>low(-1), that is the switching criteria is no longer met, then the bar does not switch back to lime or green. It stays red. If you're interested in fixing this you might want to check out Alexis' post on how he approached this problem.

[mikejhelms]

a quirk

Thanks for taking a look Alexis and your version works well except for a real-time and historical quirk. When the bars are either green or lime and the switch to maroon criteria is met, close()<low(-1) && volume()>volume(-1), it switches to red instead. The reverse is also true. When the bars are either red or maroon and the switch to green criteria is met, close()>high(-1) && volume>volume(-1), it swithces to lime instead. Unless the quirk is a result of an error I made in editing the study to accomadate the suggestions you made in the previous post. Here's my edited version.

Mike

[ACM]

Mike
As I understand the conditions you posted in a prior message (see excerpt below) a green bar cannot follow a red or maroon bar and a maroon bar cannot follow a lime or green bar. For a green or maroon bar to occur the prior bar [or PB(-1) to use your own convention] has to be lime or red respectively.
Alex

Originally posted by mikejhelms
What I would like to add is, if PB(-1) was green and PB(0) once again meets the green conditon, that is close(0)>high(-1) && volume(0)>volume(-1), then I would like it to be painted DARK green. If the following price bar, PB(+1), meets neither the red or green conditions, it would revert to regular green. In other words, within a set of for example ten consecutive green bars, I would like the program to paint DARK green any single bar that would have already been painted regular green because of the previous bar, but has once again met the green criteria. The following bars would return to regurlar green until the red criteria is met at which point they would be painted red. The same would be true in a red series. That is, if within a series of red bars a single bar should appear that once again fulfills the red criteria, that is close(0)<low(-1) && volume(0)>volume(-1), that single bar should be painted DARK red, with the rest of the series returning to regular red.

[Doji3333]

Dueling Codists..

Alex is great. He knows some thing about esignal I have not even tried to learn. I think it is great when you get two people trying so hard to help another esignal user. Hats off Alex.

Mike, try this one. I made a simple change that should resolve the problem for you in both RT and historical results. Again, just simple logic..

B

[mikejhelms]

Well, I... ahh...

Yeah, Alexis, at best my description of the criteria was murky, at worst misleading. I must have been having a bad linguistics day. Ever since those aliens took me aboard their ... well, never mind about the details.

To be consistant, all green bars and all maroon bars should fulfill their respective green and maroon criteria no matter what type of bar they follow. To that end I've modified the conditional criteria code lines you suggested, switching all greens for limes and all reds for marrons as shown below. And as far as I can see now all is well. Thanks for your help.

Mike