Through much back testing on the Dow I can see that funnily enough low values for the setting “Lookback” (eg, one to four) worked well, so it’s really the PivotBar variable that needs some ML applied to it!
(I also noticed that values for the PivotBar of around 30 to 40 worked well). Once I got an intuition about the settings you can get some interesting results (slightly biased / curve fitted because I used the same date ranges). Eg:
ignored,ignored,ignored,Dev,ignored,ignored=CALL"Kase Dev Stop Lisse+SAR+4.5/6"
c4=(close=Dev)
IFc4THEN
EXITSHORTATMARKET
ENDIF
My other thought was that instead of applying ML to a basic RSI, why not see if it can be applied to a superior indicator like John Ehler’s Universal Oscillator? (I’m going to compare to see if that is as good as his improved Stochastic Oscillator which has a roofing filter). Specifically apply ML to the bandedge setting (which is like a sensitivity period setting), because I would often get great results, sometimes for years and then boom! Inevitable losses would appear because it needed a different bandedge setting to be profitable as the markets had changed. Now if bandedge could “self optimise” that’d be pretty interesting to see.
Without optimisation and the right market regime/dates you can get some good results, this has more Universal Oscillator exits to — pls see image #2: (this test done in Mch 2017)
Ehler’s Univ Osc £/$ | 1 Hr | £18.5k | 185% | win95% | gain/loss7.9 | DDown22.5% | 03/08/2015–31/12/2015
Settings”
Spread 3.3
Bandedge =25
But it only works going forward for the next 6 months in time if the bandedge is upped to 100 and it also runs with a 100 tick trailing stop (pls see 3rd image which I just ran a test to produce). I’m hoping ML will mitigate the need for a stop too, although DDown is 51%.
I’d be happy to publish back test results between the generic RSI and the Universal Oscillator on a range of assets if you can perhaps code it or help me code it? It looks like Juanj’s code can be applied in the top part of the code but I’d need help getting the condbuy / condsell set up right. (I also noticed the RSI system was going long if the Close was < 70 when it would probably be better to have it crossing over say, 20%). The Ehler’s indicators like his Stochastic Oscillator with the roofing filter, are predictive not reactionary.
Ps/ Universal Oscillator code bandedge is 25 not 100 as above – that’s how the results came about for the second image. It was set at 100 + a trailing stop of 200 and the spread was higher at 3.8 for the last image/test.
Ps/ For anyone wanting a further understanding of how these John Ehler’s oscillators detrend and cut out noise thereby making them better at predicting market turning points, I have put this very interesting article I copied, in my Dropbox: https://www.dropbox.com/sh/epubyuln0os824g/AADJGuZwtpqlj1uqtqyIV05ca
You don’t need an account, just hit the “x” in the top right “sign up/in box” to access the document.
I imported the Indicator and changed the name to what you show in your System code but now I am getting the message attached … did you change the Indicator code also?
Best you post the .itf with the Indicator already in the System code? I’m busy on self-build tasks, but I will dive into this every now and again as a break! 🙂
Ah got it going now … I rem’d out the [100] at the end of lines that call the Indicator … what are the [100] for if it doesnt run with them but it runs without them??
Excellent job, thanks very much for taking a look at this @GraHal,
Glad you got the [100] bandedge sensitivity setting worked out, (I’d added it as variable for easier alteration and for optimisation).
Only problem is I can’t see your system yet because when I go to Auto Systems (as opposed to Indicators) and try and import your file it gives me this warning which makes no sense because (1) I’m importing a “system” not an “indicator” and (2) the file is named “bard” not “Ehler’s Univ Osc supersmoother?” (Clearly I don’t want to overwrite my existing Ehler’s Univ Osc “indicator”).
Glad you got the [100] bandedge sensitivity setting worked out,
Not sure I did? I just Rem’d it out. 🙂
It would be best to rename the Indicator version you want to retain as xxxxold and then let the .itf I posted do it’s thing?
Reason I say that is because I did a lot of changes after I posted Bard(1) and – having just checked – I can see that the results and settings are not the same.
You are supposed to rename one of the files in your file folder before reattempting the import.
When I tried to do this a few days ago in v11 it would still fail to recognise the new file even though I had renamed it so I could never import it. I reported this bug to Nicolas off forum and hopefully he has passed it on to PRT. If you are on v10.3 then simply rename the new indicator and change any CALL instructions to the new name or temporarily delete and re-import later your original version.
But the Bandedge is part of the Univ Osc – it’s like what a “Period” is to a Moving Average. I can see that the ML was applied to the 0.6/0.7 thresholds from the image you supplied. Normally the 0.8 (or 0.9) were pretty consistent in backtesting many different instruments over many different time periods but the Bandedge would always need to be changed from one market regime to another market regime.
It would be best to rename the Indicator version
I still don’t understand why we’re talking about an “indicator!?” Didn’t you create Bard.itf as a system with new ML code in it?
Thanks, I did rename the downloaded Bard itf system as Univ Osc Machine but still got the same “indicator” warning message?
How do we get v11? I log into IG and launch PRT 10.3 from there.
“simply rename the new indicator ”
Thanks for the file/name change tip. What’s confused me is that I posted a system — “Ehler’s Univ Osc” — above and was expecting the Bard.itf to be a system not an indicator.
I’ve renamed my original Ehler’s Univ Osc Supersmoother –> Ehler’s Univ Osc SupersmootXXX and successfully imported the Bard.itf ML system, (thanks again @GraHal), but why was the warning asking me to replace my Ehler’s Univ Osc Supersmoother indicator if GraHal’s only referencing that Ehler’s Univ Osc Supersmoother indicator in the ML Bard.itf code?
Now that I’ve named my Ehler’s Univ Osc Supersmoother —>> Ehler’s Univ Osc SupersmootXXX (to get the Bard ML code imported), I went and deleted GraHal’s version (because it doesn’t have the added variable I’d set mine up with).
But now when I go to change my name back to the original and remove the XXX’s, it won’t let me rename it as Ehler’s Univ Osc Supersmoother? It just gives a red text and a yellow triangle in the name field? That was the original name and bear in mind it’s being used by a large number of my Auto systems including in my demo tests.
So…. I assume that because I didn’t get why I needed to do the following:
If you are on v10.3 then simply rename the new indicator and change any CALL instructions to the new name or temporarily delete and re-import later your original version.
because I followed GraHal’s instruction and renamed my existing indicator with “XXX” (or old as he advised) I now have a problem with all my old backtest and live demo systems?
I still don’t get why there is a “GraHal version of my Ehler’s Univ Osc Supersmoother,” it’s not in the ML Bard code? Nor do I get why, having just deleted “his” Ehler’s Univ Osc Supersmoother just now, why his non variable version wold even appear in my Indicator list before I deleted it, how did it get in there?
Ps/ The confusion as to the nature of the Bard.itf file, (indicator v’s system) only came about because of the ambiguous warning terminology. That’s why I tried renaming Bard.itf first. The warning refers to Ehler’s Univ Osc Supersmoother as an “indicator,” but then it goes on to refer to it as a “program” in the next paragraph. If it has simply said “replace the existing indicator” I wouldn’t have been writing the comments above.
Any advice on how to not have to go into tons of systems and change the CALL for my Ehler’s Univ Osc Supersmoother to Ehler’s Univ Osc Supersmoother 2, would be appreciated,
The Indicator in my System was exactly the same as you had been using except that I Rem’d out the [100] in the System because it wouldn’t backtest unless I did that.
I even named the Indicator same name as you used in the System so I cant see why you are having the issue as you surely must have replaced like with like??
I’d slow down for a while until we get this sorted as you not want to lose an Indicator linked to loads of your Systems.
When you do attached … what do you see??
EDIT /PS
I should have attached the 2nd image (only) as the 1st image was on my SB Platform.
To help us continually offer you the best experience on ProRealCode, we use cookies. By clicking on "Continue" you are agreeing to our use of them. You can also check our "privacy policy" page for more information.Continue
.
