Heavy "Feature" with doubles produces unpredictable errors in EAs - page 2

New comment
 
But besides this, I stick with it. 0.5 minus 5 times 0.1 shoult not result in 2.77. 
 
Doerk Hilger: I stick with it. 0.5 minus 5 times 0.1 shoult not result in 2.77. 

It doesn't.

You originally posted

Doerk Hilger: The final result should be 0. But it is really 2.775557561562891e-17  .... !!!
2.775557561562891e-17 EQUALS 0.00000000000000002775557561562891

Reread #9 № 1 and № 2

 
Doerk Hilger:

Update: Could this be a Windows Kernel problem and that this is connected to the date and time?

It cannot be coincidence that my Frontend-Support received a message from a user just 15 minutes after I posted this, that - only since today - he has problems when he is trying to deal with lot sizes >= 0.4 and gets a margin call and all positions become closed. Of course, because 2.7 is 27x the size of 0.1. The version of the EA he is using was last updated in autumn 2018. 

I do believe its printing out in scientific e notation so,

   2.775557561562891e-17 (scientific e notation)

= 2.775557561562891 × 10 -17 (scientific notation)

= 27.75557561562900 × 10 -18 (engineering notation) (quintillionth; prefix atto- (a))

= 0.00000000000000002775557561562891 (real number)

This is where MODE_MINLOT/MODE_MAXLOT combined with a free margin check before order submission would have helped your client.

If the EA was "fail safe" so to speak, it would have checked "0.00000000000000002775557561562891" against minimum lot and reported the error or assigned the minimum lot.

simple if(n<minlot) n=minlot would have saved the account.

 

This is imho not the right way to code stuff like that, as well as NormalizeDouble isnt. This EA is available aince ca 3 yrs and used by 1000+ users day by day and there was never such an issue until this morning. By the way, nothing happened to the account, he just couldnt get filled. 

But anyway you and WR are probably/obviously right with the real number, thx. 

 
Doerk Hilger:

This is imho not the right way to code stuff like that, as well as NormalizeDouble isnt. This EA is available aince ca 3 yrs and used by 1000+ users day by day and there was never such an issue until this morning. By the way, nothing happened to the account, he just couldnt get filled. 

But anyway you are probably right with the real number, thx. 

Its good nothing happened to the account.

I try and build my code around Murphy's Law.

I anticipate pitfalls and address them before hand and still things go south.

If you work out that it was the update that led to this, kindly share your findings.

 
Doerk Hilger:
But besides this, I stick with it. 0.5 minus 5 times 0.1 shoult not result in 2.77. 

Forum on trading, automated trading systems and testing trading strategies

Heavy "Feature" with doubles produces unpredictable errors in EAs

Icham Aidibe, 2019.07.16 12:06

   printf("**** %s",DoubleToString(2.775557561562891e-17,8));
2019.07.16 10:06:09.950	xxx(EURUSD,M1)	**** 0.00000000


 

Any news / updates on this topic, @Doerk Hilger?

 
Marcel Fitzner #:

Any news / updates on this topic, @Doerk Hilger?

Doubles are working as expected, read this:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

https://floating-point-gui.de/

His example, it was printing in scientific notation(see the -17 at the end),
which means the number was almost zero which is correct.

Rouding errors like this will appear after a sequence of operations
and are normal.

12
New comment
Reason: