Libraries: BestInterval - page 23

New comment
 
fxsaber:

This is the only thing I've done so far

The rest is not required to be corrected by lots. But there are errors related to the other (old). It is necessary to correct.

Updated. In activated BestInterval mode I recommend to use this option.

Forum on trading, automated trading systems and testing trading strategies

Libraries: Virtual

fxsaber, 2019.12.11 12:15 pm.

It is difficult to say when the developers will fix the situation with the normalisation of initial symbol prices and whether they will do it at all. That's why this mode has been introduced. 
// https://www.mql5.com/ru/forum/321656/page34#comment_14192799
#define  TICKS_FORCE_NORMALIZE // Forced normalisation of incoming tick prices
 

Quite unexpected behaviour.

It seems that if you run it once with Action=false, it will save the result of the pass to a file and can apply it later. But the unexpected thing is that it will also save all parameters like Total, RF, DD, etc. In other words, if you run it with Action=true on another interval of the same symbol, another symbol, etc., it will not only apply the best time for trading, but will also lie in the log, giving the old values.

 
traveller00:

If you then run it with Action=true on another interval of the same symbol, another symbol, etc., it will not only apply the best time for trading, but will also lie in the log, giving the old values.

It does not show the values of the true run, it shows the data of the false run that was applied. You can change the symbol, interval, etc., the values it shows will not change. They are only relevant to when the entry was made. This is done on purpose.

 
Just in case, I would like to point out that from the point of view of architecture it does not work correctly with StopLoss. Theoretically, StopLoss triggered at action=false may fall into the range that BestInterval decides to throw out. As a result, when action=true it will be shifted, and the result figures can sometimes be very different from those predicted when action=false.
 
traveller00:
Just in case, I would like to point out that from the point of view of architecture it does not work correctly with StopLoss. Theoretically, StopLoss triggered at action=false may fall into the range that BestInterval decides to throw out. As a result, it will shift at action=true, and the result figures can sometimes be very different from those predicted at action=false.

It seems that you are misunderstanding something. Even theoretically there should be no problems.

 
Yes, the issue seems to be that Sync, which is included in Virtual and which uses BestInterval, ignores StopLoss and TakeProfit. The issue isn't architectural, it's me not fully figuring it out.
 
traveller00:
Yes, the issue seems to be that Sync, which is included in Virtual and which uses BestInterval, ignores StopLoss and TakeProfit. The issue isn't architectural, it's me not fully figuring it out.

I'm writing TC through limiters and takers, so it would be good to show a primitive example of reproducing the problem.

 
When active=true in BestInterval.mqh there is voidOnTick( void ), inside it SYNC::Positions<BEST_TIME>();, which will lead in Sync.mqh to staticvoid Positions( constint Handle = 0, constbool Reverse = false ). Inside, the lots are recalculated and if they fall within the required interval, they are transferred from the virtual environment to the real one via SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 100, 0, 0, 0);;. It is a bit strange that the price is not taken from the positions, but is read in place, but that's okay. As you can see, zero StopLoss and TakeProfit are passed. Perhaps you are using the BESTINTERVAL_LIMITSYNC_NETTING option, where TakeProfit is taken into account.
 
traveller00:
When active=true in BestInterval.mqh there is voidOnTick( void ), inside it SYNC::Positions<BEST_TIME>();, which will lead in Sync.mqh to staticvoid Positions( constint Handle = 0, constbool Reverse = false ). Inside, the lots are recalculated and if they fall within the required interval, they are transferred from the virtual environment to the real one via SYNC::NewOrderSend(_Symbol, Type, ::MathAbs(AddLots), Price, 100, 0, 0, 0);;. It is a bit strange that the price is not taken from the positions, but is read on the spot, but that's okay. As you can see, zero StopLoss and TakeProfit are passed. Perhaps you are using the BESTINTERVAL_LIMITSYNC_NETTING option, where TakeProfit is taken into account.

Yes, I use this mode. true-mode was made more for demonstration. I didn't even think of wasting time on a universal solution, because everything would be wasted.

If you do a little tinkering, you can use BestInterval-true for single passes of EAs with closed source code (Market, etc.).

But still, the main feature of BestInterval is working in the Optimisation mode. True is a good but not obligatory feature.

  
  int FromFile( const string FileName = __FILE__, const int CommonFlag = 0 )
  {
    const bool Res = (::FileLoad(FileName, this.Intervals, CommonFlag) > 0) && (this.IsCalculated = true);

    if (Res)
    {
      this.AmountDeleteIntervals = ::ArraySize(this.Intervals) - (this.Intervals[0].OpenTime ? 0 : 1);

      this.FullInterval.Calculate(this.Intervals);
    }
    else
      ::Print("ERROR: Can not load the File " + FileName + "!");

    return(Res);
  }
Minor cosmetic fix, int => bool. Or if I may suggest returning AmountDeleteIntervals instead.
1...1617181920212223242526272829
New comment