Right y'all - OWN UP!

New comment
 

Who was it who tainted the forum with the incrementing loop to select and close/delete orders?


CB

 

CB - that has been around for many years.

Historical garbage that just is...


Additionally, I'd posit that is somewhat more usual for coders to iterate low -> high, without even giving it a second thought.

It just transpires that doing so in Trade Pool context, could be damaging to your health!


I reckon it'll never go away. Is somewhat esoteric in nature and as such, unless one has landed on a post or specifically been informed about the issues and mechanics of the why's etc... it will never ever be considered.


btw, what got you going on this anyway?

(well, yes... it is maddening to see all the time but as I believe above... :)

.

oh - just saw 'error 4108'

.

Take yer mind offa this cr*p 'n go fly a chopper along that great Irish coast line for a few laps... :O)

 

IS THIS OK?


void close_all_trades_1()
{
   for(int i=OrdersTotal()-1;i>=0;i--)
   {        
      if(!OrderSelect(i,SELECT_BY_POS,MODE_TRADES)   )
         continue;
  
      RefreshRates();  
      if(OrderType()==OP_BUY )
         OrderClose(OrderTicket(),OrderLots(),Bid,3,White);

      if(OrderType()==OP_SELL )
         OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
   }  
}


VERY NAIVE, indeed.

void close_all_trades_2()
{
   for(int i=0;i<OrdersTotal();i++)
   {        
      if(!OrderSelect(i,SELECT_BY_POS,MODE_TRADES)   )
         continue;
  
      RefreshRates();  
      if(OrderType()==OP_BUY ) {
         OrderClose(OrderTicket(),OrderLots(),Bid,3,White);
         i--; // LOOK HERE, COUNTER GOES BACK AGAIN TO PREVIOUS POSITION 
      }

      if(OrderType()==OP_SELL ) {
         i--; // LOOK HERE, COUNTER GOES BACK AGAIN TO PREVIOUS POSITION   
         OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      } 
   }  
}


Many people now have to close with incrementing loop, in order to comply with new NFA FIFO rule.

A professional developer would firstly make a collection of all trades to close (e.g. in an array), and then iterate through the collection, with incrementing loop if the problem is the FIFO rule.

 
abstract_mind:

Many people now have to close with incrementing loop, in order to comply with new NFA FIFO rule.

Do you know whether this actually works? Simply incrementing rather than decrementing may not solve the FIFO issues. I stay well away from NFA-regulated accounts but, in another topic, I've hypothesised that MT4's order list is probably in placement-order, which isn't necessarily the same as fill-order. If so, closing orders based on their position in MT4's list could still fail to meet the NFA rules under some circumstances.

 

This should work too...

.

for(int i == 0; i < OrdersTotal(); i++){

OrderSelect(...,...,...);

if(OrderClose(...,...,...) == true) i--;

}

 

As for FIFO, some dealers are using the back-office to handle that accounting, and not disturbing the trade platform.

 
phy:

This should work too...

.

for(int i == 0; i < OrdersTotal(); i++){

OrderSelect(...,...,...);

if(OrderClose(...,...,...) == true) i--;

}

Right. Even better.

 
abstract_mind:

[...]

Right. Even better.

This still potentially isn't going to solve the FIFO issue under all circumstances. The NFA's wording implies that the FIFO rule applies based on the fill-time of trades, not the placement-time. As far as I'm aware, the MT4 order list uses placement-time. Therefore, if you place pending orders #0 and #1, and #1 is filled first, the MT4 list is not re-ordered to take account of the fact. The above code would try to close #0 first, despite #1 having been filled earlier, and should presumably fail under NFA rules.

 
jjc:

This still potentially isn't going to solve the FIFO issue under all circumstances. The NFA's wording implies that the FIFO rule applies based on the fill-time of trades, not the placement-time. As far as I'm aware, the MT4 order list uses placement-time. Therefore, if you place pending orders #0 and #1, and #1 is filled first, the MT4 list is not re-ordered to take account of the fact. The above code would try to close #0 first, despite #1 having been filled earlier, and should presumably fail under NFA rules.

You are right, placement-time must be considered, for robustness. Interesting that we can still learn with just a "Right y'all - OWN UP!" post. :-)



This placement-time issue, I think only happens if several EAs, running concurrently, are wildly trying to place trades without any coordination or synchronization. This is probably a source of many "trade context is busy" errors.

If each EA has code to ensure that whenever it places a trade it has exclusive access to the "trade context", until the current trade is complete, then the "placement order" is the same as the "time order".


Can this be a rule?:

IF "placement order" is not the same as "time order", then EAs running concurrently lack synchronization, e.g. using semaphores, and trade context errors are likely to happen.

 
abstract_mind:

[...]

Can this be a rule?:

IF "placement order" is not the same as "time order", then EAs running concurrently lack synchronization, e.g. using semaphores, and trade context errors are likely to happen.

In practice, yes, that probably covers 99% of cases. I was thinking of things like an EA which trades two classes of signal - e.g. a short-term one and a long-term one.

New comment