currency ring delima

New comment
 

Ok, I have written a couple of indicators that deal or address currency ring trading. One of them uses the iADX of each symbol in the given currency pair to show the iADX of each of the pairs in a single indicator. When the conditions are right, they trigger an open trade in the tradition of the currency pair technique.

Now the delima...

I have written the EA in a way that an EA is dropped on each pair, and they fire off their trade as the trigger signal is given on the indicator. The problem is that they are all 3 supposed to fire their trade at the same time. Sometimes I get 2 firing but not the 3rd.

So I changed the EA so that a single EA is loaded on the primary pair and it fires off the 3 trades for all 3 pairs. Problem here is that the other two pairs do not have any control of the trades belonging to them. I even created a dummy EA that maintains the MagicNumber so that their magic numbers match up.

So what is my best approach? How can I ensure that all 3 trades are fired and closed at the same time, but still work across all 3 pairs. The common solution would be to use a globalvariable, but globalvariables are buggie and not reliable.

Basically, what I think I am in the need of is to have an EA on each pair, then have a method of communicating the trigger for opening a trade, the direction of the trade to open and to close the trade.

When I get past this hurddle, I want to be able to do a 3 ring set, a 6 ring set and a 9 ring set, etc. In theory, if an account can handle it, we should be able to handle as many currency rings as is possible.

Any suggestions?

 

All you really need is one EA.
If you have the capacity to do so, make sure your EA is coded correctly to handle multicurrency trading.
This way, your interested currency pairs can be traded and maintained all the time.

If you don't know how to code it, pay somebody to do it.
Getting everything for free all the time is pathethic.

Greed begets greed and before you know it, there is STAGNATION in the economy all over again.

I know how to do it. Email me if you are interested: charlyher@businessclubworldwide.com

 
Broadly speaking there are 3 solutions:
  1. Run each expert in a different Terminal.
  2. Attach each expert to a different chart (in the same Terminal).
  3. Implement all experts in one expert.
Each solution has it's ups and downs - I'll mention the main ones:


Pros of each solution (by index)
  1. Each expert has it's own completely independent trade context.
  2. Simpler to code than other 2 solutions.
  3. Minimal system resources; much simpler persistence layer than other 2 solutions.
Cons of each solution (by index)
  1. Requires the most system resources; a Terminal-to-Terminal communication system might be needed (via shared file, shared dll memory, etc.); persistence layer is the most complex (and generally this is likely to be the least reliable solution).
  2. Experts must share the trade context (but somebody already did the work for us -> https://www.mql5.com/en/articles/1412); Expert-to-Expert communication system might be needed (but we can use GV's and a simple persistence layer).
  3. More complicated to code than other solutions; a system for launching start() for incoming ticks of other pairs might be needed (e.g. -> https://www.mql5.com/en/forum/124915); trade context is shared inherently (code is linear).

These are just the main pros and cons... As usual with any design problem there is a trade-off between complexity, reliability, system resources, etc. for each solution and there is no one 'best' solution for all situations. But for the majority of cases I think that #2 gives the best balance (especially since the trade-context code is already well documented and ready to use -> https://www.mql5.com/en/articles/1412). Anyway, that's just IMHO.
 
gordon:
[...] But for the majority of cases I think that #2 gives the best balance (especially since the trade-context code is already well documented and ready to use -> https://www.mql5.com/en/articles/1412). Anyway, that's just IMHO.

IMHO too...

I think your summary is excellent but, if you're not going to go down route #1 because of the complexity, I'd personally go for #3 rather than #2. As you say, both routes imply serial placement of trades, so there's no - significant - advantage in order execution. But it sounds like exactly the same trade entry rules must be getting evaluated in each separate EA, with the intention that they're identical and place trades at the same time. If so, it sounds simpler to do everything once and in one place. Particularly if failure to open one out of the basket of trades gives you undesirable exposure. Much easier to diagnose where/why things are going wrong if there only's one EA. What happens if it's desirable to close down the whole of the rest of the basket if one of the orders fails?

One very minor distinction between #2 and #3: if there's only one EA, and there are guaranteed to be no other EAs of any other type running, then it doesn't have to worry about the trade context. This is marginally more efficient than #2 because of the small potential latency in
the https://www.mql5.com/en/articles/1412 code between the trade-context getting released and another EA noticing.

All this on the basis that #2 can't be backtested, because each EA needs to inspect price values for all symbols in the ring, not just for its own symbol. If this isn't the case, then #2 gains an (extra) advantage over #3.

(Route #1 really is non-trivial. Quite easy to do badly. Quite hard to do robustly.)

 

I imagined there would be different opinions here. I have had a hell of time going back and forth between #2 and #3 for various projects...

One of the main reasons I tend towards #2 is it's flexibility when it comes to using many experts... If all your experts are based on the methods in https://www.mql5.com/en/articles/1412 then u can later 'mix' them as u like (as long as they're designed for a multi-expert environment...). In this regard #3 is much less flexible. Of course this goes way beyond the 'currency ring' expert question.


jjc:

(...) This is marginally more efficient than #2 because of the small potential latency in the https://www.mql5.com/en/articles/1412 code between the trade-context getting released and another EA noticing.

Yeah, that is why some of my experts are still designed as #1, they are more sensitive to latency.


(Route #1 really is non-trivial. Quite easy to do badly. Quite hard to do robustly.)
Agreed. I never tried it myself, but I can imagine a situation where this would be the only solution - imagine your client has a strategy that is divided into sub-strategies which he wants to run on different accounts. Further, these sub-strategies need to communicate some information. #1 is the only solution (for MT4...).
 
ckingher wrote >>

All you really need is one EA.
If you have the capacity to do so, make sure your EA is coded correctly to handle multicurrency trading.
This way, your interested currency pairs can be traded and maintained all the time.

If you don't know how to code it, pay somebody to do it.
Getting everything for free all the time is pathethic.

Greed begets greed and before you know it, there is STAGNATION in the economy all over again.

I know how to do it. Email me if you are interested: charlyher@businessclubworldwide.com


I am building it. I have built 2 versions, 1 is done with EA on each chart, the other is EA on one chart. The problem is that each has it's own side effect. The one with 1 EA on one chart does not allow control from the other charts on their own trades and the closure is not behaving correctly. The other one, I cannot get all 3 to sync their executions. I was actually considering a fourth that actually did the work of firing the trades, while each of the charts in the ring, managed the closure, again I am not sure that will work because the EAs on the other charts did not trigger the open trade event.

I am not asking for anything free, I am just seeking wisdom, advise, suggestion on how to best address it.

 
gordon wrote >>
Broadly speaking there are 3 solutions:
  1. Run each expert in a different Terminal.
  2. Attach each expert to a different chart (in the same Terminal).
  3. Implement all experts in one expert.
Each solution has it's ups and downs - I'll mention the main ones:


Pros of each solution (by index)
  1. Each expert has it's own completely independent trade context.
  2. Simpler to code than other 2 solutions.
  3. Minimal system resources; much simpler persistence layer than other 2 solutions.
Cons of each solution (by index)
  1. Requires the most system resources; a Terminal-to-Terminal communication system might be needed (via shared file, shared dll memory, etc.); persistence layer is the most complex (and generally this is likely to be the least reliable solution).
  2. Experts must share the trade context (but somebody already did the work for us -> https://www.mql5.com/en/articles/1412); Expert-to-Expert communication system might be needed (but we can use GV's and a simple persistence layer).
  3. More complicated to code than other solutions; a system for launching start() for incoming ticks of other pairs might be needed (e.g. -> https://www.mql5.com/en/forum/124915); trade context is shared inherently (code is linear).

These are just the main pros and cons... As usual with any design problem there is a trade-off between complexity, reliability, system resources, etc. for each solution and there is no one 'best' solution for all situations. But for the majority of cases I think that #2 gives the best balance (especially since the trade-context code is already well documented and ready to use -> https://www.mql5.com/en/articles/1412). Anyway, that's just IMHO.


Reply by index:

1. too much resource abuse.
2. I am already handling persistance layer and using IsTradeAllowed paired with a 5 count while loop for the persistance. I have attempted GV in multiple EA contructions and it has always been a failure to utilize. Which complicates the issue. If it worked reliably, where 1 EA controled it and others read it and could read the an updated change to it, then this might resolve the issue, but I have never been able to get GV to be dependable.
3. This sounds like a really tricky hotwire job, I can only think it will lead to more trouble.

I was exploring MT5 last night and came upon something that may be the problem to this situation, tell me what you think of it. Each trade is encoded with a unique ID from the EA, a sort of signature. If I could pass the ID via GV that would work, a single value set one time during init, but the trick is, how do I implement it on the trades. The tool for OrderClose does not allow you to inject the ID. It is taken strickly from the EA instance itself.

There is one other solution I could run with. I could just allow only 1 ring per terminal, then force a close all trades in the basket. This is on the one EA on one Pair and I would just use the other pairs for visual. It won't set a mark of where the trades took place on the charts. I can get it to fire the 3 trades from a single EA, i can force the closure of all trades in the basket, I was just hoping to find a way to sync between 3 pair charts to ensure they all fired.

 
gordon wrote >>

I imagined there would be different opinions here. I have had a hell of time going back and forth between #2 and #3 for various projects...

One of the main reasons I tend towards #2 is it's flexibility when it comes to using many experts... If all your experts are based on the methods in https://www.mql5.com/en/articles/1412 then u can later 'mix' them as u like (as long as they're designed for a multi-expert environment...). In this regard #3 is much less flexible. Of course this goes way beyond the 'currency ring' expert question.


Yeah, that is why some of my experts are still designed as #1, they are more sensitive to latency.


Agreed. I never tried it myself, but I can imagine a situation where this would be the only solution - imagine your client has a strategy that is divided into sub-strategies which he wants to run on different accounts. Further, these sub-strategies need to communicate some information. #1 is the only solution (for MT4...).


We seem to have missed index 4, which was to run a single EA on a single pair in the ring. Remember we already have it successfully launching the trades.

So personally from my perspective, I see #2 and #4 as viable, but they both have cons about them as initially addressed. There is one possibility that may improve the #2 scenario. I could check the basket to see if we are missing a trade, in which case, we fire another one off immediately and repeat until trade appears or some counter value terminates the attempt. If we fail, then close all of the open trades and assume a bad condition with a earning sacrifice.

 
LEHayes:

We seem to have missed index 4, which was to run a single EA on a single pair in the ring. Remember we already have it successfully launching the trades

Either u didn't understand me or I don't understand u... Your #4 is the same as #3.


I'll try to clarify: the 3 solutions I outlined are the general solutions for running concurrent experts in the same account. They vary in how they deal with two 'problems':

  1. How to deal with the trade context? -> A problem since MT4 is a single trade context platform.
  2. How to deal with different pairs/charts? -> A problem since code behaves differently according to the pair/chart it's 'attached' to (some variables/functions are affected, start() is called at different times, etc.).

The 3 solutions address these two issues differently (solutions by index):
                                        1. Each expert has it's own independant trade context; each expert is attached to it's own chart/pair.
                                        2. The experts share the trade context (via a proven method, but with a small latency price); each expert is attached to it's own chart/pair.
                                        3. The 'experts' share the trade context inherently; 'experts' are attached to a single chart/pair (all experts are coded into the same expert).

                                          So your #4 solution is actually the same as #3; instead of encoding all experts into one, u decide to run only one of them... But that doesn't solve your problem...?
                                           

                                          No, not really. If the execution is singular it fires on all 3 charts unless I code them seperately of cource, and if I give the user any controls for the others, those other than the one the EA is on, it will be difficult to manage which one is allowed to trade, not trade, how much, etc. I would really LIKE to have the EA on each pair, providing that each maintains control of their world.

                                          Not a biggie though, going through the discussion, I made a decision on it the other night.

                                          New comment
                                          Reason: