Errors, bugs, questions - page 3131

 
x572intraday #:

I can only answer for &= immediately:

MQL5 Reference Guide / Language Basics / Operations and Expressions / Assignment Operations:

In analogy to the cumulative variable y:


But this is my first experience with &=, so I could be wrong.

First, all logical conditions are summed up in accumulative h_plus inside for and the resulting bool-sum is inserted into if which has nothing to do with internal for.
But still, it would be more correct not
h_plus&=high[i]>high[i+increment];
but
h_plus = h_plus && high[i]>high[i+increment];
 
Alexey Viktorov #:

In your case this is not the case as both conditions must be met. But if you put this

then, yes. If condition "a" is fulfilled, the second condition will not be checked. This has been fought for for years, and now you're suggesting we go back to the last century...

Although... I'm wrong in this statement of mine. Apparently I don't quite understand what's written here.

x572intraday #:

I don't dare call it a bug. That's why I will simply say that I noticed one peculiarity of the if operator. I suspect it may be relevant to other written languages as well.

If a turns out to be true, check jumps to Array[over_index] and here the terminal starts crashing through the'array out of range' part, which is quite true. But if a turns out to be false, the terminal will not check for the Array[over_index] condition and hence for index redundancy, and if will skip further and the coder will not know that there is an array with a non-existing index in his program... or rather an existing but redundant one.

Maybe there should be a fix for it so that the check for 'array out of range' would be carried out to the very end of the if loop and the same message would be output? Or it will significantly reduce speed of the operator?

Even if the && condition and the first condition isnot fulfilled, the second one will not be checked. So, excuse me if I've misled anyone...

 
x572intraday #:

I already tried both break and return in the heat of the moment, but it only made things worse. I'll try to simplify the code some more and rethink it with break...

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Like this.

 

When scaling the chart by moving the mouse along the timeline, the chart runs to the left or right, depending on the direction of the mouse, so that anything that is in the user's focus of view often just disappears beyond the boundaries of the chart. This is terribly inconvenient, because then you have to look for the right place, and this has been the case since I've been familiar with MT.

It was logical to suppose that maybe clicking on the magnifying glass icon will rescale the chart to the centre, but no, the behaviour is the same as with the mouse scaling - the chart moves to the left (compression) or to the right (expansion).

Dear developers! We earnestly ask you to change chart's scaling behaviour, it is necessary to leave the centre of the chart in the centre.

Everyone with whom I discussed this inconvenience of working with the chart agree with me, so I have a good chance to be objective about this problem.

Tried to get used to it for 14 years - couldn't.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

It's like that.

Fresh idea, I'll give it a try.

As for the previous option:

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

without even trying it, it's already clear that

if(!h_plus)break;

is after the summation, which means that the terminal will see the previous line first and will understand that there is an array with an excessive index and will give the same'array out of range' message. This is the second thing. The first is that we should check not for !h_plus but for ArraySize(high)<=i+increment and escape the loop in case the index is exceeded. I tried all this yesterday, but failed in some subtleties. Yes, there was no message, but the indicator started to make a mess too.

 
x572intraday #:

As for the previous option:

without even trying it, it's already clear that

is after the summation, which means that the terminal will see the previous line first and will understand that there is an array with an excessive index and will give the same'array out of range' message. This is the second thing. And the first is that we should check not for !h_plus but for ArraySize(high)<=i+increment and escape the loop in case the index is exceeded. I tried all this yesterday, but failed in some subtleties. Yes, the messenger was gone, but the indicator started to make a mess as well.

So the trouble here is

i<rates_total-3
I wrote
i<rates_total-n
for a reason, and the early kicking out of the loop is precisely to simulate the if() calculation
 
x572intraday #:

I don't dare to call it a bug. So I'll just say that I've noticed one peculiarity of the if statement. I suspect this may apply to other languages as well.

If a turns out to be true, check skips to Array[over_index] and here the terminal starts crashing through the'array out of range' part, which is quite true. But if a turns out to be false, the terminal will not check for the Array[over_index] condition and hence for index redundancy, and if will skip further and the coder will not know that there is an array with a non-existing index in his program... or rather an existing but redundant one.

Maybe there should be a fix for it so that the check for 'array out of range' would be carried out to the very end of the if loopand the same message would be output? Or it will significantly reduce speed of the operator?


If you set variable a to false, control is passed on and doesn't affect the array or the code in brackets after if, because in your case

if(a && Array[over_index]>val) {...}

control will be passed to the right part of the condition only if the left part (a) is true

if, for example, you do

if(check(over_index) && Array[over_index]>val) {...}

where check function checks for array Array,you'll never get "array out of range". So, you can check array index and address it in one if. But to pass control to second part of if with && operator, if first part is false, hardly possible in any of existing programming languages...

 

There is one problem, it appears randomly and occasionally.

Appears when working in the tester with several currencies.

In each cycle I request actual prices for symbols. If for some reason the tester does not receive quotes for a particular symbol, it uses the quotes obtained earlier for another symbol.

I should open a position if the price is higher than the specified one. I should open position if I got wrong data from another symbol.

EURCAD symbol opens if the price is above 1.45117. 1.74425>1.45117? Yes, it is higher but it is the price of another symbol.

We have detected 7 erroneous orders out of 500.

 
Yury Lemeshev #:

There is one problem, it appears randomly and occasionally.

Appears when working in the tester with several currencies.

In each cycle I request actual prices for symbols. If for some reason the tester does not receive quotes for a particular symbol, it uses the quotes obtained earlier for another symbol.

I should open a position if the price is higher than the specified one. I'm using wrong data from another symbol for opening.

EURCAD symbol if the price is above 1.45117 then it opens. 1.74425>1.45117? Yes, it is higher but it is the price of another symbol.

We have detected 7 erroneous orders out of 500.

The problem is in the code, but the telepaths are already celebrating and when they come out of their sleep, they will say that the error is in the line 123652

 
Alexey Viktorov #:

Problems in the code, but telepaths are already celebrating, and when they come out of their binge, they will say that the error is in line 123652

There is no error in the code, the code was rewritten to eliminate the error, and the error does not appear regularly, it is completely chaotic

Reason: