Errors, bugs, questions - page 589

New comment
 
Ashes:

You have to look outside the box (c)

I don't see any contraindications to running a separate cloud run (except price).

A standalone run in the cloud will be slower in many cases than on the local core.
 
joo:
An individual run in the cloud will be slower in many cases than on the local core.
Abovehttps://www.mql5.com/ru/forum/1111/page598#comment_125691 is a scenario. Note the word CAN. The limitation seems farfetched.
 

A problem has arisen.

In the code of indicator in OnCalculate() there is this line (or more precisely some similar lines):

ArrayInitialize(FractalsBuffer,EMPTY_VALUE);
The FractalsBuffer is not an auxiliary calculation buffer, but rather the main buffer responsible directly for the graphical plotting, so it must necessarily be linked:
SetIndexBuffer(0,FractalsBuffer,INDICATOR_DATA);

that has been done. But the bind function has some direct effect, which sometimes acts as a side effect (in a bad way). Through CopyBuffer(ind_handle,0,0,amount,FractalsBuffer) the buffer is filled not for the whole length of timeframe history, but only partially, from its small segment, by the amount. But ArraySize(FractalsBuffer) clearly convinces us that the size of the buffer (i.e. occupied physical memory) will correspond to the number of bars of the whole history, i.e. in the end it will be fully occupied including the ineffective part. Of course, if you want to work with the buffer values later in the loop, you don't have to search through the whole buffer - you can just specify the necessary limits and work within these limits. But first, it doesn't cancel out the horrible memory overallocation and, second, the inevitable function in the code ArrayInitialize does not allow to initialize buffer with necessary value partially, you have to spend time and wattage on full re-initialization. This makes the indicator run noticeably slower. And third, a quote from the description of the ArrayResize function: "Andyou should keep in mind that . it is impossible to resize dynamic arrays that are assigned as indicator buffers by function SetIndexBuffer()."If we rejectSetIndexBuffer infavour of manual manipulation of the buffer size using ArrayResize, the indicator chart itself will collapse.

Please suggest a recipe for recovery. Or consider this as an application to fix this problem in the language itself.
 
x100intraday:

It's kind of messed up...

1. it makes sense to initialize the buffer once, at start if(prev_calculated==0)

2. You can set from which bar the data will be drawn, like this: PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);

3. All the values in the buffer within the amount should be assigned explicitly, once throughout the history, and then only the new values will be assigned, then they don't need to be initialized.

4. In the terminal settings decrease the number of bars in the window :)

 
Swan:

It's kind of messed up...

1. it makes sense to initialize the buffer once, at start if(prev_calculated==0)

2. You can set from which bar the data will be drawn, like this: PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);

3. All the values in the buffer within the amount should be assigned explicitly, once throughout the history, and then only the new values will be assigned, then they don't need to be initialized.

4. In the terminal settings decrease the number of bars in the window :)

1. Really: at idea level - it makes sense to do it only once, but in practice it is not so simple, everything is really running. I just copied from the standard indicator: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. How to clear the buffer before new calculations in a different and more effective way - I don't know.

2. I haven't studied this possibility yet, but it looks like not drawing of the indicator in an unnecessary zone, but it doesn't limit the size of the indicator buffer. Besides, I'm much more willing to work with a buffer that is filled tightly with useful data, without any free margin, otherwise I'll have to introduce bounds (about which I told in previous post), and it doesn't fit to orthodox algorithm: out of four buffers three will be scanned in one loop with the same bounds, and for one buffer I will have to take my time and do a separate curve loop with different bounds, that I can hardly ever squeeze in. Although yes, you can also crawl on crutches...

3. What do you mean by explicitly? I don't vouch for not assigning explicitly at all. It may well be that I am explicitly appropriating. Explain? As for loading only new values - of course I use that, it's called a parsimonious algorithm here.

4. This idea was rejected before writing the previous post, because the indicator needs several last (new) bars of history, while for me personally (visual aspect) I need all or nearly all the bars. My human interest in the history bars is wider than the interest of a technical indicator in them. I want to look at the bars and draw the indicator within one chart. A whim? An ordinary need.

 
x100intraday:

1. Indeed: at idea level - it only makes sense to do it once, but in practice it's not that simple, everything is really running. I just copied from the standard indicator: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. How to clear the buffer before new calculations in a different and more effective way - I don't know.

   if(prev_calculated<7)// if(prev_calculated==0)// if(prev_calculated<1)// вопщем одинаково)
      //Initialize только при первом запуске. нуу или при случае какогнить ахтунга)
      {
      limit=2;//цикл начинается со второго элемента индикаторного массива
      //--- clean up arrays//в принципе здесь не очистка массива, 
                        //а значения EMPTY_VALUE  присваивается 0 и 1 элементу массивов, мм.. и на последних трёх барах)
                        //остальные определяются далее в цикле..
      ArrayInitialize(ExtUpperBuffer,EMPTY_VALUE);
      ArrayInitialize(ExtLowerBuffer,EMPTY_VALUE);
      }
   else limit=rates_total-5;//иначе - в цикле пересчитываются только два последних значения

//зы: при появлении нового бара - новый элемент массива вроде как не определен, насколько мне известно не гарантируется, что он будет  ==EMPTY_VALUE
2. I haven't studied this possibility yet, but it looks like not drawing of the indicator in an unnecessary zone, but it doesn't limit the size of the indicator buffer. Besides, I'm much more willing to work with a buffer that is filled with useful data right up to the bounds, without any free margin, otherwise I would have to introduce bounds (about which I told in previous post), and it doesn't fit to orthodox algorithm: out of four buffers three will be scanned in one loop with the same bounds, and for one buffer I will have to take my time and do a separate curve loop with different bounds, that I can hardly ever squeeze in. Although yes, you can crawl on crutches too...

Well, yes, it should.

The size of the indicator buffer is defined only by the number of bars.

One way or another, some size will have to be set... Why make a curved loop with different boundaries when you can make a straight one with the same boundaries)

In other words, you should specify the loop size, not the array size... Otherwise, the indicator will be based on crutches


3) What do you mean "explicitly"? I absolutely cannot guarantee that I do not assign it explicitly. It may well be that I do explicitly. Explain? As for loading only new values - of course I use that, it's called here a parsimonious algorithm.
      //---- Upper Fractal
      if(High[i]>High[i+1] && High[i]>High[i+2] && High[i]>=High[i-1] && High[i]>=High[i-2])
         ExtUpperBuffer[i]=High[i];//условие выполняется - присваиваем значение
      else ExtUpperBuffer[i]=EMPTY_VALUE;//не выполняется - таки тоже присваиваем значение)
//нет зависимости от Initialize, всем элементам в цикле явно присваивается значение.

About the thrifty algorithm - I'm not sure that you use it.

The indicator is calculated once for all bars - i.e. it may be a little sluggish when launched on an agromadic history.

Subsequently a couple of values are recalculated - everything should work :)

 
Cmu4:

What's the bug with the indicators? They come and go. And only the ones in a separate window!!!

Here's a screenshot of when the indicators disappeared. They disappear now and then appear... arbitrarily. There's a video too...

Attention, the basic indicators are disappearing!!! It means that the bug is significant. There is the same problem with custom indicators.

Gentlemen developers, fix this bug, please, it's not nice somehow...

Unfortunately, the screenshot does not show.

What server? What access server? What date/time? Was the story paging at the time?

Is it happening again now? Can you attach the terminal logs for this date?

 

Dear developers, I've found an unpleasant error (flaw) in the MQL5 compiler.

If you use a conditional construct of the following form

if (Condition) ;

{ operator_1

......

Operator_N }

No errors or warnings are generated when compiling the code.

But since there is a " ; " (with or without spaces) right after the condition, {operator_1...operator_N} will be executed all the time.

MQL4 shows a warning. I want MQL5 to display error or warning too! (I've lost half a day trying to find out what's wrong with my code)

Thank you for your feedback!

 
Fia:

Dear developers, I've found an unpleasant error (flaw) in the MQL5 compiler.

If you use a conditional construct of the following form

if (Condition) ;

{ operator_1

......

Operator_N }

No errors or warnings are generated when compiling the code.

But since there is a " ; " (with or without spaces) right after the condition, {operator_1...operator_N} will be executed all the time.

MQL4 shows a warning. I want MQL5 to display error or warning too! (I've lost half a day trying to find out what's wrong with my code)

Thank you for your feedback!


Everything is valid in this case. ; is an empty operator.

We'll think about your suggestion (issuing a vorning), but it's not the highest priority at the moment.

Документация по MQL5: Основы языка / Операторы / Оператор-выражение
Документация по MQL5: Основы языка / Операторы / Оператор-выражение
  • www.mql5.com
Основы языка / Операторы / Оператор-выражение - Документация по MQL5
 
alexvd:

In this case everything is valid. ; is an empty operator.

We will think about your suggestion (issuing vorning), but it is not the highest priority at the moment.

I hope you will not forget to do it in MQL4, as it was logically done in MQL4.


Could you please advise us to consider two pending orders (price, type and volume of their execution are the same)?

When the price is reached, both events will be triggered, and how will the OnTrade() event work in this case?

In particular, pending orders that have been executed will go to history in one OnTrade() event or will there be two calls? (my logs show one call for some reason)

Thank you for your reply!

1...582583584585586587588589590591592593594595596...3191
New comment