Community of Expertise - page 3

New comment
 
komposter<br / translate="no">
Had a quick look (haven't done any digging yet) , found the point reference that you're calculating.
Try "throwing it out" and putting stupid Point. Maybe that's the problem (point through MarketInfo may not always come out the way you want?).

It's always supposed to...
although you can try to normalise it too =)

and it's not always acceptable - expert may trade on several pairs, and the point may be different...
 
The problem is as old as the first computer chip -
it's sad, of course... but there's got to be a way around it, right? I hope Renat will say something...
  
if ( orderstoploss == 0.0 || (  orderstoploss < ( bid - TrailingStop * point ) ) )


Suppose orderstoploss = 1.29211 (5 digits after the decimal point)
bid=1.29716 (also 5 digits )
TrailingStop = 50
point =0.001
then (bid - TrailingStop * point)=1.29216>1.29211
True, this requires that digits suddenly become 5
And also

if ( orderstoploss == 0.0 || (  orderstoploss < ( bid - TrailingStop * point ) ) )


can be painlessly replaced with

if ( orderstoploss < ( bid - TrailingStop * point )) )


I think it is not necessary to check on absence of stop loss level when trailing.
Actually it is, I'm correcting myself. If we set a stop loss only when there is a profit, and if not we are willing to wait for a margin call.
I have not found anything else. On which pair did your trailing stop work incorrectly and was there any strong movement?

 
Hi.
I am converting everything to integer values for comparison purposes. I store and use the given values wherever I can (in the array).
use the given values (in arrays, variables, etc.)
I.e. variables of the int type may take values from -2147483648 to 2147483647.
This dimensionality is quite suitable for crosses.
Correspondingly, 1.2999 and 1.3000 can be cast to 12999 and 13000, and then they can be safely compared,
without fear of any periodic screw-up.

I've sketched an example here :) 
int Normalize(double double_value, int digits) - приводит double в int  (1.2999 в 12999)
double Restore(int int_value, int digits) - приводит полученный ранее int в double (12999 в 1.2999)


here

//+------------------------------------------------------------------+
//|                                                   ShiftPoint.mq4 |
//|                                                            Begun |
//+------------------------------------------------------------------+
#property indicator_chart_window
#property indicator_buffers 1
#property indicator_color1 Blue
//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
{
   return(0);
}
//+------------------------------------------------------------------+
int Normalize(double double_value, int digits)
{
	return (NormalizeDouble(double_value,digits)*MathPow(10,digits));
}
double Restore(int int_value, int digits)
{
	return (NormalizeDouble((int_value/MathPow(10,digits)),digits));
}
//+------------------------------------------------------------------+
int start()
{
	double	Test_Value =  1.29999999;
	int	Test_int;
	double	Test_double;

	Test_int         = Normalize(Test_Value,Digits);
	Test_double   = Restore(Test_int,Digits);
	Print("-----------------------------");
	Print("Restored value    = ",DoubleToStr(Test_double,Digits));
	Print("Shift Point Value = ",Test_int);
	Print("Real Double Value = ",DoubleToStr(Test_Value,8));
}
//+------------------------------------------------------------------+



output:
shiftpoint EURUSD,H1: Real Double Value = 1.29999999
shiftpoint EURUSD,H1: Shift Point Value = 13000
shiftpoint EURUSD,H1: Restored Value = 1.3000

 
In general, replace this with
if ( orderstoploss < ( bid - TrailingStop * point )) )


at 

if ( TrailingStop < ( bid -orderstoploss)/ point  )


Alternatively.

 
Thank you all for your participation!
Rosh 17.04.05 22:29 <br / translate="no"> it seems to me that checking for absence of stop loss level is not necessary for trailing
I disagree, trailing should be unambiguous - if on, it means SL is exposed.

On which pair did your trailing not work properly and was there no strong movement?
now the expert is running on eu - occasional errors... throughout the day... I don't think that's the case...

In general, replace it.
now i'll try it, maybe it will help ;) i'll tell you tomorrow...

Begun 17.04.05 22:46
Hi.
I bring everything to whole numbers for comparison
Hi =) it's certainly an option... but I didn't think I'd have to go through all this trouble... I wish I'd heard from the developers, they know better than me...
 
Apologies, wasn't involved in the discussion.

2dev:
The problem is as old as the first computer chip:

You are right - this is a fundamental problem, it is dangerous to compare floating point numbers.
In important places, always bring numbers to a certain precision via Normalize().

which implementation of arithmetic do you use?

Standardize on type double (8 bytes).

By the way, we force normalize all passed prices in trade queries to avoid errors.
You can send a request for a stop loss as 1.2932461, but it will be set as 1.2932.
Please check if this is the error in trying to re-set the stop at the same price?
 
Please check if this is the error with trying to re-set the stop at the same price?

3 people were watching =)) Renat came and just pointed his finger at the error =)))
I will check now, of course, but most likely this is the case... I haven't normalized "bid - TrailingStop * point", and this very construction is involved in order modification...
we are not attentive, gentlemen ;)
 
In important places, always bring the numbers to a certain accuracy via Normalize().

do you mean the Normalize() that Begun suggested?
 
В важных местах постоянно приводите числа к определенной точности через Normalize().

do you mean the Normalize() that Begun suggested?

Sorry, I meant the standard NormalizeDouble.
1234567891011
New comment