Rank: Member
Groups ready for retrieval: Registered, Registered Users
Joined: 3/19/2012(UTC)
Posts: 13
|
Hi All,
Looking for help with understanding how to program latches. I have read Roy Larsen's tutorial and done multiple searches gathering what I could from Wabbit's posts, but I have to admit, the references are still starting a bit above my head. I will attempt to clarify what I am looking to do.
My basic goal is to identify the BAR of entry into a position, either short or long ( I realize this will require separate and opposite formulas); and from this bar, be able to reference one of the four OHLC prices for use in exit strategies.
Borrowing from one of Wabbit's postings, here is what I see for latch programming.
N:=Fml("Long Trades")=1;
X:=N=0; {not long trades}
I understand this part (I think) and have created a formula based on the entry. (Although this is not quite true as the formulas won't let me use Optimizations, but we will deal with that separately)
The next part I need to do is understand how to code the actual reversal.
For example, here is what I am after on a LONG position for the SELL.
1. the entry LONG was on BAR X
2. I need the system to remember BAR X - LOW
3. and then if the BAR X - LOW price is surpassed, the trade is REVERSED to SHORT
Any help would be appreciated as when I try my versions I am getting entry and exit signals the same day, and not the reversals I am looking for.
Thanks
Darren
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered, Registered Users, Subscribers
Joined: 7/25/2005(UTC)
Posts: 1,042
Was thanked: 57 time(s) in 54 post(s)
|
Hi Darren
I doubt it's possible to tell you all you need to know about latches in one reply, so I'm not even going to try. The purpose of a latch is to "remember" an event, state or value, and there are several ways you might go about this, depending on what it is that you wish to remember.
In a simple latch you might want to know when a long trade is active; this can be tracked by...
BarsSince(entry)<BarsSince(exit); For this to work the entry and exit signals must be completely independant of each other. Also, it can only be used for one side of the market and, typically you would need a second latch to monitor the other side. That is unless you're always in the market and can use the inverse side of the long latch to represent the short side.
One problem with this (and at least one other type of latch) is that the first historic trade on any chart or data will be missed. This is because the first entry signal often has no exit signal to reference to and so the BarsSince(entry)<BarsSince(exit) line of code returns an N/A until one of each signal has been received, and will plot zero until the first entry signal after a valid exit signal.
The fix for this is to OR an initialisation signal separately with both the entry and exit signals. The initialisation signal tells us that both entry and exit signals are valid (we're only interested in the first bar they are both valid), and the leading edge of this I (initialisation) signal can then function simultaneously as both an initial "entry" and "exit" signal. As these initial signals are simultaneous the
BarsSince(entry OR I)<BarsSince(exit OR I) does not allow the latch to go TRUE, but what is does do is prepare the latch to capture the first real entry signal.
I:=Cum(IsDefined(entry OR exit))=1;
BarsSince(entry OR I)<BarsSince(exit OR I);
Similar latches can be built using ValueWhen() and incorporate the same initialisation signal is required.
A third type of latch generally uses 2 or more PREV variables. PREV enables decisions to made inside the latch rather than externally. This allows for exit signals to be related to entry signals, and storage of a value as well as a condition. For example, the entry price can be stored by a PREV latch as well as the trade condition (positive value for long trade, negative value for short trade and zero for no trade). However, attempting to do this is not without its problems, especially for the novice MFL user.
PREV-based latches lend themselves to trailing stops, and the reverse also applies. They also create very slow code. Getting too adventurous and trying to track both sides of the market in one PREV latch can quickly become a nightmare in terms of both coding and execution speed.
In my opinion simple latches are pretty easy to understand. Get hold of some code, experiment with it, and you'll quickly learn what its strengths and weaknesses are. PREV-based latches are a different story and understanding them can take lots of time and practice. If you reply to this post I'll look through old MSTT newsletters and pick out some latch examples for you to start working with.
Roy
|
|
|
|
|
|
Rank: Member
Groups ready for retrieval: Registered, Registered Users
Joined: 3/19/2012(UTC)
Posts: 13
|
Hi Roy,
Thanks for the reply. The confusion I am getting is how to reference a specific event as well as how to keep the original trade from coming back into play.
Truthfully, I don't understand why Metastock doesn't have this reference built in as many trades styles are based on what happened on the day of entry. Therefore, why is there not a simple reference we can use such as 'entrybar' which would contain the OHLC of the bar. Why all the complicated code just to reference these 4 hard prices on a set bar? Or is there something that does this and I am just missing it?
So using this simplified code, my exit/reversal strategy would be thus:
IF(PRICE<"low of entrybar")
Done!
If this is doable, then great, please let me know what I am overlooking. If not, I am still stuck on how to make the latches function properly.
Please understand that I am in now way venting my frustration at you and certainly appreciate your knowledge and help, but I am searching the forum and seeing these exact same questions back to 2006 and wonder why Metastock has not had their development team create a simple reference.
Sorry for my digression....getting back to the subject.
The system I am currently testing uses Stochastic and Stochastic MA as one trigger. Of the two lines, one is higher than the other at any given time. Depending on which determines if Long or Short.
What I am looking to do as I mentioned above is to reference the ENTRYBAR; then reference the FIELD within the ENTRYBAR (either OHLC); and REVERSE position if the reference is hit. However since the original entry signals may still be there, keep it from reversing back the next bar (hope that makes sense). Like this on a long trade for example:
IF (PRICE<"low of ENTRYBAR) THEN reverse trade;
AND
IGNORE all LONG entry signals until AFTER a true SHORT entry signal has passed
Again, hope that makes sense...and thanks again for the help.
Cheers,
Darren
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered, Registered Users, Subscribers
Joined: 3/6/2010(UTC)
Posts: 113
Location: London
|
Hi
This is how I write latches, subject to the limitations as set out by Roy above:
http://forum.equis.com/forums/thread/41655.aspx
There is a function that gives you the number of bars in a position, that is the Simulation.CurrentPositionAge, but beware this is VERY SLOW and it's best if you code it yourself rather than rely on it.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered, Registered Users, Subscribers
Joined: 7/25/2005(UTC)
Posts: 1,042
Was thanked: 57 time(s) in 54 post(s)
|
Hi Darren
Well, I suspect that there's no one answer that will solve your problem, but probably several issues that you need to address.
No matter how much we wish MetaStock was different, in reality it is what it is. While I've done my share of complaining over the years I have found that trying to figure out solutions is always more productive than wishing MS was different/better/whatever.
You mention your buy long signal is still active when you go short. Is there a reason why you don't truncate the long entry signal to just a leading edge? In real life are you going to enter a new trade on every bar simply because the entry signal is valid for several bars? Probably not, so just kill the signal after the first bar and inhibit it until the raw signal has gone FALSE again. This is easy as...
Entry:=Entry*Alert(Entry=0,2); And some alternative ways of writing the same thing.
Entry:=Entry AND Alert(Entry=0,2);
Entry:=Entry AND Ref(Entry,-1)=FALSE;
It's good to have the ultimate goal clearly fixed in your head, but even so it's unlikely that you'll realize all the little problems that need to be solved along the way. With any significant project there are time issues, logic issues and a variety of other problems popping up to spoil your day. Solve one problem at a time and you'll eventually get there.
Haddison mentions the Simulation functions. There are quite a number of these but he's right, they are VERY SLOW and you should only use one if you're prepared to wait to the end of the year for a result. Or use several and wait until the end of the decade. Seriously, though, make a habit of constructing your systems as indicators first (Simulation function not available), and only when you can see that the indicator does what you want should you move it across to the EST (my opinion anyway).
When creating a system as an indicator it's easy to monitor what each variable does and whether it performs as it should. Unfortunately it's not always as easy to fix problems, but it is less messy that troubleshooting with the EST. PREV-based latches function in the EST exactly the same way as they do in indicators. Personally I never use Simulation functions in the EST.
Just a few random thoughts
Roy
|
|
|
|
|
|
| Users browsing this topic |
|
Guest (Hidden)
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
