Is it just me or has the fxDreema server been very poor for everyone?
I am in Brazil but have an excellent internet connection at 600Mbps up and down here locally and to NY and London over 100Mbps up and down.
I have tried 2 different PC's, tried both Firefox and Chrome and restarted my router various times but no improvement.
Extremely frustrating!!
Looking forward to some feedback.
Thanks!!
@TXZZ you've probably already looked into this but is it necessary to process these blocks every tick?
Your EA would be MUCH more efficient if you could process these blocks every M1, M5 or maybe even a higher TF?
@bacharchoura1 no need to be sorry.
Try to invest some time into studying as much as you can in the fxDreema builder menus and work out how it all functions and you will save yourself a lot of time in the future.
@bacharchoura1 are you aware that you can "normalize" the block ID numbers automatically?
Go to Options -> Project Options -> Project Blocks: Normalize IDs.
@fxDreema it would be greatly appreciated if you could update fxDreema functions to be in accordance to the recent MetaQuotes changes.
Very annoying to have these compiler warnings that are mentioned previously in this thread that we have no control of.
Calculations can vary a lot from one broker to another, especially with indices.
The only reliable way to know how a particular broker calculates pips, points, and lot sizes is to do your own testing by opening positions and seeing what happens.
Unless you are very courageous and ready to make costly mistakes, test on a demo account of the broker you use.
As @jstap suggested, this should work:
@fishhy While there is no trade present and your condition block is true it will send a notification every execution.
Add a once per bar block or make sure the condition can only be executed once.
Also note that MetaQuotes restrict the amount of notifications that can be sent.
See here:
https://www.mql5.com/en/docs/network/sendnotification
So now you know how it works, apply it to your needs and build up your EA.
Good luck.
@Manuel-M in your shared project you are drawing the line every tick if there is no position.
It will then get deleted at 13:00 and on the next and susequent ticks get drawn again.
Is that really what you want to do?
There is no doubt as to which method is better; obviously the slow complete algorithm.
But the fast genetic method may be useful to give you an idea of what to expect or what ranges to use.
The most important points to consider with the slow method are to reduce as much as possible the amount of parameters to optimize and secondly reduce the amount of steps of each parameter to optimize.
The video in the link below does a good job of highlighting some of the risks of the fast genetic method.
https://youtu.be/CtQ9qU1v3No
@s00071609 just to clarify the situation; your original method of calling the various time stamps through a "Value" and then "Time" still does not function correctly, all return the server time.
The method of calling time through "Market Properties" and then "Time" does function correctly for all time stamp types.
So, the left side block in the below screen shot functions correctly, the right side block does not.
@s00071609 A bit late to the party here but this is a very simple solution by using Market Properties:
https://fxdreema.com/shared/QdX8oPs0e
From you log extract the error is occuring in the EA at line 1418, position 62 so maybe you could have a look there and see if it gives you a clue.
I forgot to add that you will need to set the variable "s1_buy_newest_profit" to zero in a modify variables block before the for each position block.
@Johnster your variable "s1_buy_newest_profit" will be updated with a new value for each position on each iteration of the loop so it will only have the last value when the loop completes.
Declare a new double variable as "temp" and put it where "s1_buy_newest_profit" is in the modify variables block.
Add a new formula block after the modify variables block
Put "s1_buy_newest_profit" as the left operand
Put "temp" as the right operand
Add the 2 together and put the result back into your "s1buy_newest_profit" variable that will become be the result of the sum of the loops.
I’ve been wondering how fast the MQL5 programming language actually is so I made a tiny script using fxDreema to test it.
MQL5 is based on C++ and it is known to be pretty quick.
The script is very simple, it will run a specified amount of iterations of a “while loop” and on completion print results to the experts tab.
Here it is:
https://fxdreema.com/shared/tgzUPoVUb
In the Custom MQL Code block a counter will continue to add 1 to itself until it reaches the setpoint.
The while loop will then complete and the result will be printed to the experts tab.
If you want to try it you can either save it as an .mq5 file and compile it or compile it directly as an .ex5 file and put it in your MT5 scripts folder.
From there just pull it onto any chart and specify how many billions of loops you want it to run.
If I run 100 billion loops on my PC it takes about 87 seconds to complete or in other words about 1.15 billion loops per second; that’s quite impressive!!
I have an Intel i9 10900k.
I ran the same test in Python and it was about 75 times slower.
But, note that a trading EA has many blocks with a huge amount of fxDreema underlying code so any EA will obviously be many thousands of times slower than this test script.
Always try to keep your code efficient.
Have fun!!
You are probably totally aware of the following but the easiest way to reduce optimization time is to reduce the amount of optimization passes.
If there are 5 parameters to optimize and each parameter has 100 steps it will produce 100 x 100 x 100 x 100 x 100 = 10,000,000,000 passes when using the slow complete algorithm method.
If it can be reduced to 4 parameters then it will produce 100 x 100 x 100 x 100 = 100,000,000 passes.
If it can be reduced to 50 steps then it will produce 50 x 50 x 50 x 50 = 6,250,000 passes.
So, the original example has 1,600 times more passes than the last.
This is a very exaggerated example but it highlights the effect of reduced (efficient?) parameter selection.
