Errors, bugs, questions - page 2451

 
A file with a # in its name cannot be added to the storage. Is this normal behaviour or a bug?
 

If we are talking about FX, there the ticks do not change the price much (usually). But in other markets an order can seriously slip with a ticky approach. I'm still in favour of trying between ticks - I don't see any harm, potential benefit is there.

We have to try...

 
Hysteresis in action... on an example of how an implicit assignment copy operator works in structures.

#define  PRINT(x) Print(#x, ":", string(x))

struct MyArray{
   uchar data[];
};


void OnStart(){
   MyArray tmp_arr;
   
   MyArray huge_arr;
   ArrayResize(huge_arr.data, 1000);
   ArrayInitialize(huge_arr.data, 0x8);
   
   MyArray small_arr;
   ArrayResize(small_arr.data, 10);
   ArrayInitialize(small_arr.data, 0x1);
   
   
   tmp_arr = small_arr;
   Print("\r\nTest with small_arr");
   PRINT(ArraySize(tmp_arr.data));
   PRINT(tmp_arr.data[0]);
   PRINT(tmp_arr.data[ArraySize(tmp_arr.data)-1]);
   
   tmp_arr = huge_arr;
   Print("\r\nTest with huge_arr");
   PRINT(ArraySize(tmp_arr.data));
   PRINT(tmp_arr.data[0]);
   PRINT(tmp_arr.data[ArraySize(tmp_arr.data)-1]);
   
   tmp_arr = small_arr;
   Print("\r\nTest with small_arr");
   PRINT(ArraySize(tmp_arr.data));
   PRINT(tmp_arr.data[0]);
   PRINT(tmp_arr.data[ArraySize(tmp_arr.data)-1]);
}

Result:
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   Test with small_arr
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   ArraySize(tmp_arr.data):10
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[0]:1
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[ArraySize(tmp_arr.data)-1]:1
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   Test with huge_arr
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   ArraySize(tmp_arr.data):1000
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[0]:8
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[ArraySize(tmp_arr.data)-1]:8
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   Test with small_arr
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   ArraySize(tmp_arr.data):1000
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[0]:1
2019.05.03 14:29:14.005 Test_push (EURUSD,H1)   tmp_arr.data[ArraySize(tmp_arr.data)-1]:8
 
Sergey Dzyublik:
Hysteresis in action... by an example of how an implicit copy operator works in structures.

Probably, to detect such a thing, one had to reach an internal state/stupidity of "nothing can not work here, but I will check it anyway" in search of an error in one's code.

 
fxsaber:

I guess to detect such a thing, you had to get to the internal state/stupidity of "nothing can go wrong here, but I'll check it anyway" in search of a bug in your code.

The code was parsing the byte stream for a particular protocol.
Unpacked and unpacked data (data for the next level of encapsulation) did not match.

 
Sergey Dzyublik:

The code was parsing the byte stream for a specific protocol.
Unpacked and unpacked data (data for the next level of encapsulation) did not match.

It's not hard to detect such a task. Lucky.
 
Sergey Dzyublik:
Hysteresis in action... An example of how an implicit copy operator works in structures.

What is the question?

void OnStart()
{
        int a[]; ArrayResize( a, 3 ); ArrayInitialize( a, 3 );
        int b[]; ArrayResize( b, 2 ); ArrayInitialize( b, 2 );

In MQL, a conditional entry

//                 a = b;

equals

        ArrayCopy( a,  b );

Result:

        ArrayPrint( a );
}

2 2 3

 
A100:

What's the question?


In my opinion, the assignment copy operator should copy not only the array elements themselves, but also their number, leaving the amount of reserved memory valid.

And now it's practically the following:

int size;
size = 4; // size == 4
size = 8; // size == 8
size = 4; //  size == 8



Source code:

struct MyArray{
   uchar data[];
}

MyArray GetArray(int i){
   MyArray arr;
   
   if (i%2 == 0){
      ArrayResize(arr.data, 8);
      ArrayInitialize(arr.data, 0x8);
   }else{
      ArrayResize(arr.data, 4);
      ArrayInitialize(arr.data, 0x4);
   }
   return arr;
}

void OnStart(){
   MyArray arr_1 = GetArray(1);
   ArrayPrint(arr_1.data);		// 4 4 4 4
   
   MyArray arr_2 = GetArray(2);         
   ArrayPrint(arr_2.data);              // 8 8 8 8 8 8 8 8
   
   arr_2 = arr_1;
   ArrayPrint(arr_2.data);              // 4 4 4 4 8 8 8 8
}
 
Sergey Dzyublik:


The copy operator should copy not only the array elements themselves, but also their number, leaving the amount of reserved memory intact.

Why then

struct MyArray {
        uchar data[];
};
void OnStart()
{
        { uchar   a[], b[]; a = b; } //(1) Error
        { MyArray a,   b;   a = b; } //(2) нормально
}

in (1) the error and in (2) it's fine!? What's the difference?

The difference is that copying of arrays is not performed by the a = b rules, but by the ArrayCopy( a, b ) rules.

Not by the rules a = b, because it doesn't exist, and if it did, error (1) wouldn't exist


 
Igor Zakharov:

Counting on every tick is resource-intensive, especially in the strategy tester. Wouldn't it be more correct to recalculate only the Trade event, i.e. when something in the list of open positions actually changes? With OnTradeTransaction(), it is easier to control user intervention in the EA. (There are some precedents :)

In this robot I was testing the possibility to close the grid by the scheme: Loss + profit > X , then close both of them (usually on different symbols). But a failure occurs, because even though they are closed, the tester is not aware of it, and proceeds to the next iteration, mistakenly "pairing" the existing ones with those already closed. I.e. I had to add a recalculation after each closure.

I have recalculation with counter reset and on all open ones first, not +1 / -1

I agree, it was risky to initially use OnTradeTransaction() Actually, I will probably refuse to use it in cases where my requests are not asynchronous - they cause only troubles.

It is not risky at all. The question is only in organizing the sequence of actions and events. Fool's advice is correct - close the pair and leave the loop until the next tick. At the next tick, the prices are not necessarily worse than they are. Maybe, it will be better to close it a little bit later, but there will be no confusion about what closed with what.

The second variant: arrange the loop not by PositionsTotal, but by the array created beforehand. And when closing some pair, these tickets should be removed from the array. This will not allow the closed positions to be closed again. In general, a flight of fancy and logic of actions.

Reason: