Community of Expertise - page 2
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 you trace a stop with an accuracy of a pip, the broker will howl and cut off the Expert Advisors :)
I think this is better:
if (MathAbs(CurrentStopLoss - NewStopLoss) > (Ask - Bid)*Koef) { // Modify stop loss ................ }I.e. we modify the order if the new stop differs from the old one by a given number of spreads (1 - 2).
Your problem is automatically solved here.
Only here the problem is different - it tries to set _to_the_ same_value_... I.e. such check will not save from error, but just reduce its probability =)
It's most likely a glitch in the EA's text.
I had a similar one, I don't remember how it was fixed.
But the example above ensures that any errors in the script
there will be no attempts to set to the same value.
It's most likely a glitch in the expert's text. I had a similar one, how it was fixed, I don't remember. But the example above ensures that any errors in the script will not try to set to the same value.
Mak, there is 1 line of text there =
I wrote the function precisely to avoid such errors, and the check is the same, with the difference that every pip is worked out.
If the value is the same (distance from the price to the stop is equal to 50 in this case) trailing stops should not work.
Moreover, in most cases it does not work =)))), and sometimes it slips through for some reason ....
Does it round off or discard?
Generally speaking, it is better never to compare floating types for equality.
The only exception:
And about one line ...
In _TrailingStop there are a lot of lines,
and if there are even 2, there is already a reason for errors :)
I've already partially corrected it here: instead
made
and the rest seemed fine:
Renat, I'm generally pinning my hopes on you =) there's probably something as simple as an angle here - and I just don't notice...
komposter, you're wrong :) As the spoon-bending girl said, "things are not what they seem".
For example, the following loop prints 5 numbers:
How much will the next cycle print with the boundaries increased by 1.0?
You could expect to print 5 numbers too, but it only prints 4 (four). Isn't that great?
If another line is added after the loop:
Print("d=" + d + "(d <= 1.5)=" + (d <= 1.5));we get:
Almost like yours with a stop, but more fundamental :). The problem is as old as the first computer chip:
Computers use binary arithmetic and humans use decimal arithmetic. When rounding, artefacts appear.
"Rounding up", which Mak suggested, helps if you have a fundamental problem with rounding, not a trivial bug.
Many people think that financial calculations MUST USE special decimal arithmetic libraries, but even these can contain errors, sometimes
which can sometimes have serious consequences. By the way, Renat, which implementation of arithmetic do you use?
Had a quick look (haven't done any digging yet), found the point reference that you're calculating.
Try to "discard" it and put Point. Probably that's the problem (point in MarketInfo may not always come out the way you want it?).