Hi Exito

Somewhere between 2000 and 2002 (admittedly with liberal help and prompting from others) I came up with the idea of using an "Initialization" bar to manage the introduction of unnecessary and unwanted N/A bars into custom formulas. It came about at a time when a group of us were working on a "simple" latch to remember when a trade was active.

Buy:=Fml("my buy conditions");

Sell:=Fml("my sell conditions");

Trade:=BarsSince(Buy)<BarsSince(Sell);

Trade;

The problem with this simple latch (by simple I mean not PREV based) is that it completely misses the first trade and has an extended N/A period. The problem is solved by introducing a one-bar-only signal that returns a TRUE as soon as all feeding variables become valid.

Buy:=Fml("my buy conditions");

Sell:=Fml("my sell conditions");

I:=Cum(Buy+Sell>-1)=1;

Trade:=BarsSince(I OR Buy)<BarsSince(I OR Sell);

Trade;

This definition of "I" is only suitable for logical values (TRUE and FALSE) and would need to be rewritten for use with oscillators and moving averages etc. With the introduction of an IsDefined() function with MS 7.0 it became possible to create an I-bar that worked with all values irrespective of their type.

Buy:=Fml("my buy conditions");

Sell:=Fml("my sell conditions");

I:=Cum(IsDefined(Buy+Sell))=1;

Trade:=BarsSince(I+Buy)<BarsSince(I+Sell);

Trade;

In the latches above the I-bar serves as a dummy Buy and Sell signal. Since both simulated signals occur on the same bar they are ignored by the BarsSince() test but provide a reference point into each BarsSince() function that the other function can access.

To some extent an I-bar needs to be constructed to suit the variables it has to work with, but the underlying principles remain whatever code it’s used with.

There needs to be an understanding of what causes N/A bars, otherwise once an I-bar has been created it’s very easy to introduce another N/A bar that invalidates the good work already done. Any function that uses a Periods parameter that’s greater than 1, an Nth parameter, or meets certain other criteria will generate additional N/A bars and render an I-bar virtually useless. When this happens the problem (if indeed it is a problem) can be resolved by regenerating the I-bar so that it encompasses any and all additional N/A bars.

Typical "flies in the ointment" are Cross(), Ref(), ValueWhen(), BarsSince(), HighestSince() etc. Using any one of these (or their cousins) following the creation of an I-bar WILL invalidate that I-bar unless steps are taken to prevent that from happening. For ValueWhen() the solution is most often to simply use the existing I-bar ORed with the normal trigger for ValueWhen(). Sure, this might produce a value that you don’t want, but there are ways to check whether this is a real or simulated value and adapt your code accordingly.

Depending on how it’s being used Ref() can often be substituted by ValueWhen() or Alert(). This might seem rather odd but ValueWhen() and Alert() do not force a progressive accumulation of N/A bars in the same way that Ref() and functions using a Periods parameter can and do.

Obviously I’ve not been able to cover the subject fully here but I hope that at least readers can see that the N/A bar situation need not be treated as insurmountable. There are solutions, even if those solutions are not well understood by most MS users.

I have many examples of how I-bars can be used in custom formulas but it is not appropriate for me to share these in an open forum. Feel free to contact me at rlarsen@quik.co.nz if you need further help or information.