Errors, bugs, questions - page 2451
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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...
Result:
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.
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.
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.
Hysteresis in action... An example of how an implicit copy operator works in structures.
What is the question?
In MQL, a conditional entry
// a = b;
equals
ArrayCopy( a, b );
Result:
ArrayPrint( a ); }
2 2 3
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:
Source code:
The copy operator should copy not only the array elements themselves, but also their number, leaving the amount of reserved memory intact.
Why then
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
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.