Menu
Sister Sites

Options

Bookmark Thread

First Page First Unread Last Page Last Post

Print Thread

Similar Threads

Can anyone convert the Blessing 3 v3.9.6.09 into MT5? 9 replies

Blessing EA by ananthhh 13 replies

Blessing Multipair EA 447 replies

'Blessing' EA Modification Wanted 3 replies

Forward testing results of my ea modified from Blessing 3.9.6 18 replies

Attachments: Most Famous Blessing 3.9.6 EA and Setfiles
Exit Attachments

Most Famous Blessing 3.9.6 EA and Setfiles

Quoting richard96816
I think a higher timeframe trend option might be helpful. I've seen some impressive systems that trade on the weekly basis. Forex seems to work well in that realm. If we had a good higher trend indicator we could have it control the ForceMarketCond parameter and do interesting things. Might work ...
Blessing3 has its Blessing MA channel to determine the market condition - Trend Up , Trend Down and Ranging conditions based on the timeframe of the chart it is running.

I think it would be better if the market condition should be fixed and can be user input option. I have mine set to Daily independent of the chart timeframe which the EA is running.
Honesty is a very expensive gift. You wont find it in cheap people.WBuffett
Quoting richard96816
I don't know everything about Blessing. But I can get you started optimizing well in a hurry, if you pay attention. {file} That set file has parameter ranges already set and the important optimizable ones already checked. They are in groups, as you can see in the Blessing menu. ATRTF, ATRPeriods, GAF (Stop optimizing ATRTF after the first pass.) ProfitSet, MoveTP, TotalMoves EEHoursPC, EEStartLevel, EELevelPC (You could leave these alone until the last pass. Whatever ...) MACDEntry, FastPeriod, SlowPeriod, SignalPeriod (Stop optimizing MACDEntry...
Yes, MACD is good. Stoch also produces well. Here is a pass E/U 5 min. from 1/1/17 to 7/14/20. 2nd chart is with MACD ENTRY, all else unchanged.
Attached Image(s) (click to enlarge)
Click to Enlarge Name: TesterGraph.gif Size: 29 KB
Click to Enlarge Name: TesterGraph MACD.gif Size: 30 KB
Vincit qui se vincit.
Hi,

This is my first post after few years of "missing in action" due to other life commitments ;-)

I did few backtests for WTI Crude Oil Spot CFD, here is my best result so far.

Broker: ICMCapitalVC-Demo (Build 1264)
Symbol: #WTI. (WTI Crude Oil Spot CFD 1 USD)
Test Period: 2020.01.01 - 2020.06.30
Timeframe: M5
TickData Source: Tickstory

The DD is quite high, but it is as suggested in default B3 setting. Anyone else doing backtest for Crude or Brent? I will refine the backtest more soon. I will be looking at fine tuning CCI and MACD - any advise on these indicators?
Attached Image (click to enlarge)
Click to Enlarge Name: Capture.GIF Size: 25 KB
Quoting RJ1
any advise on these indicators? {image}
No, not yet ;-)
I did some manual trading on WTI, more or less gambling. Won and lost...

But please do me a fovour, once you already have the tester running: start the tester with different dates (take a look at the historic data and find some extremes) and see whether your set-up will still survive.
As the tester is cummulating wins, the DD depends on the success you had bsfore. If there was a big winning streak, then some extremes can be survived. If you enter at the wrong day(s) or take your wins and start with a lower equity, then you might get broke more often.
Quoting ursinho4711
{quote} No, not yet ;-) I did some manual trading on WTI, more or less gambling. Won and lost... But please do me a fovour, once you already have to tester running: start the tester with different dates (take a look at the historic data and find some extremes) and see whether your set-up will still survive. As the tester is cummulating wins, the DD is depends on the success you had bsfore. If there was a big winning streak, then some extremes can be survived. If you enter at the wrong day(s) or take your wins and start with a lower equity, then...
Yeah sure, good suggestion. WTI was ranging from Q4 of 2019 until mid Jan 2020. From Jan 2020, the price spike-up a bit and started trend down until mid April before rallying up again until end of June 2020. So, the price got haywire there. Anyway, I will again test the setfile from from Oct 2019 until June 2020 to see how it goes.
Attached Image (click to enlarge)
Click to Enlarge Name: Capture1.GIF Size: 33 KB
There is another thing that really puzzled me is the UseCloseOldest (default is False). Have anyone tries to set this to True and compare the outcome with when it set to False?

Thanks!
Quoting peretz777
Hi @richard96816, Do you know why Blessing is using a temp file on the disk to track open trades? There is a huge performance hit by doing so. I would think this can and should be replaced with a global variable? However I'm still fairly new to MT so I may be way off here too... Peretz
It appears that the file is used to save trades to disk in the event of loss of power, etc. This isn't needed for backtesting so I have added a couple of conditionals to prevent file access when back-testing. Initial results show a 4-5x performance improvement!!

Let me clean up the code and I'll share it later today.
Quoting peretz777
{quote} It appears that the file is used to save trades to disk in the event of loss of power, etc. This isn't needed for backtesting so I have added a couple of conditionals to prevent file access when back-testing. Initial results show a 4-5x performance improvement!! Let me clean up the code and I'll share it later today.
No, Blessing ,like most MT4 EAs recovers just fine from shutdown or power loss without doing anything special.

The SaveStats option is for saving equity stats according to the comments. I've never used it.

There shouldn't be any slowdown if you turn off the option. Since it probably only outputs during opens or closes it really shouldn't have much impact either way.
Quoting richard96816
{quote} No, Blessing ,like most MT4 EAs recovers just fine from shutdown or power loss without doing anything special. The SaveStats option is for saving equity stats according to the comments. I've never used it. There shouldn't be any slowdown if you turn off the option. Since it probably only outputs during opens or closes it really shouldn't have much impact either way.
Hi Richard,

There is another temp file being used in addition to the stats file. The file is checked on init and tries to set TbF (line 582). The file is then checked quite frequently as trades open/close (line 1155 and 1188), and written to if a trade closes. I haven't deciphered all the logic yet so I'm not really sure what its doing.

After wrapping the above 3 sections in conditional statements to exclude back testing I'm seeing anywhere from 2-5x improvement (I run my testing in a VPS so it can run continuously).

I'm fairly confident this is a really good step forward, so I've updated the version to 17 per your numbering and am attaching it here. Interested to know your feedback after reviewing it.

Cheers
Attached File(s)
File Type: mq4 Blessing_3_v3.9.6.17.mq4   162 KB | 293 downloads
Quoting peretz777
{quote} Hi Richard, There is another temp file being used in addition to the stats file. The file is checked on init and tries to set TbF (line 582). The file is then checked quite frequently as trades open/close (line 1155 and 1188), and written to if a trade closes. I haven't deciphered all the logic yet so I'm not really sure what its doing. After wrapping the above 3 sections in conditional statements to exclude back testing I'm seeing anywhere from 2-5x improvement (I run my testing in a VPS so it can run continuously). I'm fairly confident...
Thanks. I'll take a look.

I'd much prefer you didn't jump into the same numbering/naming scheme. That makes a bit of a mess of keep track of things for me and for other users.

Edit: Good catch, I guess. I'm not seeing much difference, but VPSes are often memory constrained which might make disk writes more frequent. If it works for you it will probably help others.
Quoting richard96816
{quote} Thanks. I'll take a look. I'd much prefer you didn't jump into the same numbering/naming scheme. That makes a bit of a mess of keep track of things for me and for other users.
Any chance we could get it into github for easier collaboration?
Quoting peretz777
{quote} Any chance we could get it into github for easier collaboration?
That sounds reasonable.

My main concern is keeping things working properly, continuing to match the manual and maintaining compatibility with the original where possible. Speed has been a driving concern, so your efforts in that area are appreciated.

I had not intended to take over primary development, it just happened. I had been using my own naming convention. Then someone else posted a version .10 and it was broken, so I posted an .11 to fix it and reduce confusion. (Everything here is based on the original version .09.)
Quoting peretz777
{quote} Hi Richard, There is another temp file being used in addition to the stats file. The file is checked on init and tries to set TbF (line 582). The file is then checked quite frequently as trades open/close (line 1155 and 1188), and written to if a trade closes. I haven't deciphered all the logic yet so I'm not really sure what its doing. After wrapping the above 3 sections in conditional statements to exclude back testing I'm seeing anywhere from 2-5x improvement (I run my testing in a VPS so it can run continuously). I'm fairly confident...
After a few optimizations with your v17 I don't find any improvement. But I have run into some problems where I had to start optimizations over from scratch. Not good.

Something seems wrong. Please remove it.

I suggest no one download version 17. :-(
I think put your initials next to the version name. It might be better naming convention for keeping track on all.
Quoting peretz777
{quote} Hi Richard, There is another temp file being used in addition to the stats file. The file is checked on init and tries to set TbF (line 582). The file is then checked quite frequently as trades open/close (line 1155 and 1188), and written to if a trade closes. I haven't deciphered all the logic yet so I'm not really sure what its doing. After wrapping the above 3 sections in conditional statements to exclude back testing I'm seeing anywhere from 2-5x improvement (I run my testing in a VPS so it can run continuously). I'm fairly confident...
I got more than 2x speed up when optimizing due to less I/O operation involved. However, The var OTbF (Order Time by File?) can't be fetched from file and it won't be set to appropriate value under your implementation. I think this variable is used to calculate Early Exit Percentage when you turn on "UseEarlyExit" in the setup.
It doesn't seem to work for me. After a few passes I lose all the optimization gains and end up starting over.

Definitely no speed-up with that. Asynchronous file reads and writes are not slow. File opens and closes can be slow. Especially for MSWindows. The files in question are only 4 bytes long, which suggests all kinds of possible speedups. The file open should probably happen only once, during init and never closed. That's a rewrite.

For those with slower systems a speedup for this might be helpful. Though using a fast SSD or RAM drive may help too. I didn't notice a speed increase on my system before it failed.

Blessing is more complex than it's 4000 lines of code suggest. I know about patching the code without understanding everything about it. If you do that you MUST do extensive testing before posting. And use a naming convention that indicates it's a test version, possibly unstable. I usually test for weeks over many optimizations and forward tests before posting. Blessing proper is no longer is test phase, it's been in production for a long time.

Thanks for your efforts.
Here's a minor update that adds a parameter to the menu: MA_TF.

This was previously hardwired in the code to Current (0). Since MA is Blessing's trend indicator it makes sense to expose the timeframe setting for adjustment. It appears to be helpful in optimizations I've done so far. Particularly with an H4 setting when the current timeframe is H1. Reversing that offset is occasionally helpful for lower timeframe setups.
Attached File(s)
File Type: mq4 Blessing_3_v3.9.6.18.mq4   158 KB | 700 downloads
Attached File(s)
File Type: ex4 Blessing_3_v3.9.6.18.ex4   280 KB | 503 downloads
Quoting richard96816
It doesn't seem to work for me. ...
Thanks for having a look at it, and yes after looking at it with a fresh set of eyes I can see that I have skipped over some logic that needs to be kept in there. My VPS claims to be running on SSD, however I am getting a significant performance improvement by skipping the disk reads/writes. I'll take some more time and replace the temp file with a global variable in order to keep all the original logic intact.

You can download "perfmon" to see what I mean about the file access (filter by process name = terminal.exe). I only went looking because I when I was optimising the CPU was stuck on ~60%. That signifies there is a bottleneck somewhere else. After getting rid of the temp file, optimisation now flatlines the cpu at 100% - like it should, and I reap the performance gain.

I agree that the naming convention could be better. Suggest getting it into github so you can control the master but we can maintain different development branches, etc. Although I have no plans to go changing much.
Quoting peretz777
{quote} Thanks for having a look at it, and yes after looking at it with a fresh set of eyes I can see that I have skipped over some logic that needs to be kept in there. My VPS claims to be running on SSD, however I am getting a significant performance improvement by skipping the disk reads/writes. I'll take some more time and replace the temp file with a global variable in order to keep all the original logic intact. You can download "perfmon" to see what I mean about the file access (filter by process name = terminal.exe). I only went looking...
Thanks.

That sounds like a reasonable plan.

I'm running a Windows emulator under Linux which tends to speed a number of system's things up, especially file I/O. An optimization run does tend to switch between processors quite often which suggests the disk-bound problem you mention.

I've got 25 terminal instances running at the moment forward testing many Blessing instances each, and often 5 or six others doing optimization. On this computer, anyway. My trading computers are separate. Speedups are a good thing. That's how I got started with Blessing mods, with the Once per Bar stuff.

It's not my place to monopolize the code or control it. If others have good ideas and time and skills to implement them you're welcome to contribute. I don't understand everything about Blessing, though I'm learning more and more over time. I much prefer to use it. But I'm aware that it can be improved.

I keep toying with the idea of automating optimization. That could save a lot of time. It's been done before, but I haven't seen anything recent. Someday.

Finally, we need to keep track of all changes since .15 so we can apply them to the mt5 version when it arrives. My hope is we can combine the two with if-defs so they will become one file and be supported together. Assuming that doesn't create too much of a mess, or that the mt5 version isn't so incredible we never go back. :-)

Thanks.
Quoting richard96816
{quote} Thanks. That sounds like a reasonable plan. I'm running a Windows emulator under Linux which tends to speed a number of system's things up, especially file I/O. An optimization run does tend to switch between processors quite often which suggests the disk-bound problem you mention. I've got 25 terminal instances running at the moment forward testing many Blessing instances each, and often 5 or six others doing optimization. On this computer, anyway. My trading computers are separate. Speedups are a good thing. That's how I got started with...
what about to upload the source code on github/gitlab ?
2 members viewing:
van8d2
,
batchlapa