[WARNING CLOSED!] Any newbie question, so as not to clutter up the forum. Professionals, don't go by. Can't go anywhere without you. - page 793

New comment
 
artmedia70:
Aren't we opening Buy at Ask price ???????


That's what I wrote: "Buy orders are opened at Ask price".

But on the chart you see the Bid price.

 
PapaYozh:


That's what I wrote: "Buy orders are opened at Ask price".

But on the chart you see the Bid price.

I always have both prices on the chart... In the terminal settings by F8 I enabled the display of Ask` prices... I have also corrected a little the previous post about the spread - it cannot be like that.
 
artmedia70:
Aren't we opening a Buy at Ask ??????? And there cannot be a spread of 60 pips (if you take it after the gap), and if you take it before ... then the spread on the EUR of 325 pips is tantamount to ... :)

your picture does not show points.
 
PapaYozh:

your picture doesn't show the points.
Yes, I repent .... it can be misleading (like the brackets in your post, where they made me lose the meaning of your answer about the asks and answered in the wrong way... :) )
 
artmedia70:
I always have both prices on the chart... In the terminal settings I enabled the display of Ask`ts by F8... And corrected a little the previous post about the spread - it can not be.


But the Ask price is not visible in the bars.

About the spread. Is it a five-digit spread? If yes, widened spread on news + slippage = that's 6 full (60 five-digit) pips for you

 
PapaYozh:


But the Ask price is not visible in the bars.

About the spread. Is it a five-figure spread? If yes, then extended spread on news + slippage = that's 6 full (60 five-digit) pips

That's the thing: four-... :(
 
PapaYozh:

If I understood your problem correctly, you should not be guided by the closing time of the order. You have to start at the beginning of the bar at which the signal to open and the position was opened. What I would do, personally, is the following:

1) create a variable of datetime type where I would enter the value Time[0] if the order is successfully placed;

2) in the init() function, initialize this variable with value "0". I prefer an explicit initialization, since it is more clear when reviewing the code;

3) when conditions for opening a position appear, before sending OrderSend(...) request, compare the value of this variable with the value Time[0] and if they aren't equal, send a request.

4) if the position opened, I would store the value of Time[0] in the same variable.


Thanks for the clarification - but do you think that instead of comparing with Time[0] value, try to give this task before the OrderSend(...) request : check if there is a StopLoss-y close on the current bar? Then I need to input duble StopLoss() function which will work with StopLoss variable I announced? Or it is NOT POSSIBLE as a matter of principle? It is important to me that a new position is not opened on the bar which has caught a loss, even if it matches the parameters of the opening.

extern double Stoploss           =1000;
//+------------------------------------------------------------------+
//| Check for open order conditions                                  |
//+------------------------------------------------------------------+
void CheckForOpen()
  {
   double ma;
   int    res;
    
//---- go trading only for first tiks of new bar
   if(Volume[0]>1) return;
//---- get Moving Average 
   ma=iMA(NULL,0,MovingPeriod,MovingShift,MODE_SMA,PRICE_CLOSE,0);
//---- sell conditions
   if(Open[1]>ma && Close[1]<ma)  
     {
      res=OrderSend(Symbol(),OP_SELL,Lots,Bid,30,Bid+Stoploss*Point,Bid-Takeprofit*Point,"",MAGICMA,0,Red);
      return;
     }
//---- buy conditions
   if(Open[1]<ma && Close[1]>ma)  
     {
      res=OrderSend(Symbol(),OP_BUY,Lots,Ask,30,Ask-Stoploss*Point,Ask+Takeprofit*Point,"",MAGICMA,0,Blue);
      return;
     }
//----
  }

The matter is that the timing factors should be considered last - very often they slip - or rather the interpretation of an order somehow turns out to be different (ambiguous).

 
obla4ko, create a datetime variable x and let it be the opening time of the bar where the stop loss occurred. And in open condition set that (Time[0]!=x). In this case x should be updated on a new triggered stoploop. This is the first variant. And the second, as I am writing for the third time, after a triggered stop switch on waiting for 1 bar, this would be exactly the same, isn't it logical?
 
PapaYozh:


But you can't see the Ask price in the bars.

About the spread. Is it a five-figure spread? If yes, then spread widened on news + slippage = that's 6 full (60 five-digit) pips

Also, in my opinion, there may be a "hairpin", subsequently cleaned up :)), but "saved in the memory" of smaller timeframes, which you won't get to...

And the question about testing on the history :

can an Expert Advisor (a simple one!) - ... but not a grid) on the same period of history, with the same parameters, would it give completely different results?

The only thing I did, between these two tests, was to update the quotes archive... and that could have led to such a result!? - then it turns out that the whole story is bullshit!?

 

Can someone tell me why MathRound() behaves strangely. Large values count, small ones don't...

There is a simple code for increasing values of some variables by 10%:

if (IncreaseTP) 
   {
      LastTakeProfitS = MathRound(LastTakeProfitS+LastTakeProfitS/100*PercentTakePr);  // PercentTakePr = 10; (десять процентов) эту строку считает
      TStartS = MathRound(TStartS+TStartS/10*PercentTakePr);                          // а вот эту и все, которые ниже - нет
      TStop.Sell = MathRound(TStop.Sell+TStop.Sell/10*PercentTakePr);                 // ... причём, если деление на 100 заменить на деление на 10,
      TStartLastPosS = MathRound(TStartLastPosS+TStartLastPosS/10*PercentTakePr);     // ... то начинает считать и эти строки, но уже, естественно...
      if (TStop.SellLP<=Level_new+spread) TStop.SellLP=Level_new+spread;               // ... рассчёт становится неверным...
   }

The calculated values are logged. If all lines except the first one are divided by 10, then this one counts as number 100 and there's no problem with it:

2010.08.11 19:16:20 2009.01.02 10:34 Sergitas_v1.01 EURUSD,M5: Function of calculation: SLs = 11 and TPs = 66, TStartS = 60, TStop.Sell = 20, TStopLastPosS = 60, TStop.SellLP = 25

What is marked in green is what counts in the first line of code.

But if you put division by 100 (as it should be)

if (IncreaseTP) 
   {
      LastTakeProfitS = MathRound(LastTakeProfitS+LastTakeProfitS/100*PercentTakePr);  // PercentTakePr = 10; (десять процентов) эту строку считает
      TStartS = MathRound(TStartS+TStartS/100*PercentTakePr);                          // а вот эту и все, которые ниже - нет
      TStop.Sell = MathRound(TStop.Sell+TStop.Sell/10 0*PercentTakePr);                 // ... причём, если деление на 100 заменить на деление на 10,
      TStartLastPosS = MathRound(TStartLastPosS+TStartLastPosS/100*PercentTakePr);     // ... то начинает считать и эти строки, но уже, естественно...
      if (TStop.SellLP<=Level_new+spread) TStop.SellLP=Level_new+spread;               // ... рассчёт становится неверным...
   }

... then all lines except the top one don't count at all - the initial values remain, as if they weren't added

ten percent:

2010.08.11 19:41:03 2009.01.02 10:34 Sergitas_v1.01 EURUSD,M5: Function of calculation: SLs = 11 and TPs = 66, TStartS = 30, TStop.Sell = 10, TStopLastPosS = 30, TStop.SellLP = 15

Help me to understand what and where the fuck it is... :)


1...786787788789790791792793794795796797798799800...1145
New comment
Reason: