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
3 people were watching =)) Renat came and just pointed his finger at the error =)))
I'll check it now, of course, but that's probably the problem... I haven't normalized "bid - TrailingStop * point", and this very construction is involved in order modification...
We are not attentive, gentlemen ;)
So several people have offered you this variant of the problem. Even I wrote that bid may have 5 decimal places. I thought at first it wasn't possible, but then I remembered that the quotes are made by an automaton that probably takes quotes from several datafeeds and averages them using some kind of algorithm.
Bid/Ask have unambiguously standard symbol accuracy. Another thing is that instead of 1.6666 you may see 1.6665999 (due to floating point error).
I want to note: problems comparing these numbers(type double) exist in _all_ languages and are a consequence of the basic limited precision of this type of arithmetic. Consequently, one should not blame anyone, but be aware of the problem and write protected code.
Bid/Ask are clearly of standard character accuracy. Another thing is that instead of 1.6666 one may see 1.6665999 (due to the peculiarities of floating-point error).
I want to note: problems comparing these numbers (type double) exist in _all_ languages and are a consequence of the basic limited precision of this type of arithmetic. Correspondingly, you should not blame anyone, but be aware of the problem and write secure code.
So I'm not accusing anyone. I didn't ask komposter for nothing - on which currency trailing didn't work correctly. I remember for sure that in MT3 you can see 3 decimal places in Yen. At least, I have seen it more than once.
we are not attentive, gentlemen ;)
normalization didn't help =(
more precisely - trailing errors (euro - buy position):
03:41
12:07
12:11
14:31
14:33
14:36
14:39
14:44
14:46
14:47
14:48
(server time)
Renat, how should I proceed?
At the moment there are 3 options:
1. if ( orderstoploss < ( bid - TrailingStop * point ) ) replaced by if ( TrailingStop < ( bid -orderstoploss) / point )
2. Compare int, not double, using Begun functions
3. Change stop advance ( not every point, but after n spreads)
and their combinations, of course.
Since the software is quite responsible, I would like to get (! not a guarantee!) recommendations for writing...
Try instead:
write:
Will there be errors as well?
It's clear that you can make a backlash, but it's not serious.... And if I have to make a 10-20 pips backlash, "for reliability", yes, on M30, just a fairy tale =)
Please recheck your code again, simplify it, insert debug messages.
To be honest, I don't know how to simplify it...
But you can check it, of course. Here is the code as it is used now (in parts):
check incoming parameters and select required order. If an error occurs, we simply exit, i.e. the order will not be modified...
Save all order data into variables and normalise them:
this is the colour and "niceness" of the log...
now, for a long position, define a new SL level, normalize it and compare it with the old one (only if the position is profitable)
dump it into the log
a triple attempt to modify the order after a 10 second pause (the order is highlighted each time)
and only if ordermodify <= 0 an error code is sent
if after 3 tries the order is not modified, we exit (-1)
then the same for sell positions
and finally, if there is no need to modify the stop, exit(0)
don't know....
What does this have to do with it? "+Point" solves the problem of rounding the last significant digit of price. We are not talking about 2, 3, and all the more about 10-20 pips.