Analogue to iBarShift - page 13

 
Nikolai Semko:

Indicator showing the performance of the iBars function compared to the built-in Bars and the iBarShift function from @Alain Verleyen
Function execution time in microseconds.


This is not the place to go - go to the kodobase. Both iBars() and iBarShift()

 
Nikolai Semko:

The iBars feature, although rather cumbersome, I still recommend it instead of the regular Bars until MQ fixes the hang-up bug in it.

You can still speed it up by doing the following.

start_time -= start_time % PeriodSeconds(timeframe);
TimeCur -= TimeCur % PeriodSeconds(timeframe);

The iBar hangs when logically it should return 0. As a rule, it returns it for more than 10 seconds. This bug does not exist in MQL4.

This call

SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE)

It works incorrectly - it causes history loading when it should not exist. Hence the lags (see appearance of hcc files).

 
Nikolai Semko:

An indicator showing the performance of the iBars function compared to the built-in Bars and the iBarShift function from @Alain Verleyen
Function execution time in microseconds.

Again, performance should be measured where it is needed - Optimiser.

 
Artyom Trishkin:

Not here - in the kodobase. Both iBars() and iBarShift()

Yes, I plan to. Let's test it for now.

 
fxsaber:

You can also speed it up by doing the following

Start_time is already implemented there from the beginning, but withTimeCur, you can speed it up a bit. Will do. Thanks.

By the way, it is only good from M1 to D1. W1 has to be moved by three days because 01.01.1970 is Thursday. And with MN1 you have to play with diamonds, because a month can be 28,29,30,31 days.

This call

This call doesn't work correctly - it causes history to be swapped out when it shouldn't be. Hence the lags (you can see the appearance of hcc files).

Strange, haven't seen such behaviour.

fxsaber:

Again, performance should be measured where it's needed - Optimizer.

What do you mean by optimizer?

 
Nikolai Semko:

Withstart_time there is already implemented from the beginning

Implemented with an error. For example, M1 starttime == D'12:00:05'. Stoptime also needs to be done.

What do you mean by optimizer?

Optimisation mode in the tester.

 
fxsaber:

Implemented with an error. For example, M1 starttime == D'12:00:05'. Stoptime needs to be done as well.

Explain what the error is? And why only time and where is the date?

Bars and iBars give 0 for this format.

 
Nikolai Semko:

Explain what the error is? And why just the time and where is the date?

I was too lazy to write the date.

t=start_time-(start_time-1)%PerSec;

Substitute start_time with a non-zero number of seconds in a minute in this line.

 
fxsaber:

I was too lazy to write the date.

In this line substitute start_time with non-zero number of seconds in a minute.

It's all right. It's not a mistake. It should be.

Try running the code like this:

   Print(Bars(_Symbol,PERIOD_M1,D'2018.04.04 18:00:00',UINT_MAX));
   Print(Bars(_Symbol,PERIOD_M1,D'2018.04.04 18:00:01',UINT_MAX)); //результат на единицу меньше
 
Nikolai Semko:

It's all right. It's not a mistake. It should be.

Try running code like this:

Then I don't understand why Bars thinks that 18:00:01 belongs to M1-bar 18:01 and not 18:00.


By the way, TimeCurrent should be replaced with SYMBOL_TIME.