Fibonacci retrace backtest for PRT – collaboration project
Forums › ProRealTime English forum › ProOrder support › Fibonacci retrace backtest for PRT – collaboration project
- This topic has 55 replies, 6 voices, and was last updated 6 years ago by
Meta Signals Pro.
-
-
11/28/2016 at 11:51 PM #17435
Can’t understand why I can’t see an entry for my Commit / Merge with the Master … see 2 screen shots attached.
If you Maz have to do a final Approval then you’d think it would say (on my profile) Awaitng Approval or similar??
11/29/2016 at 9:45 AM #17449I made some changes too this morning, just started to explore your code though.
The idea is great and setup are “visual”, but how do you want to manage the Fibonacci “redraw” when the current low is piercing the pre-defined lowestlow? about entries ..
I mean we can eventually make the autofib a better indicator, but I believe we may firstly define how to use for market entries? Or did I miss this part? (sorry then).
11/29/2016 at 11:06 AM #17460Great – that’s a question I was looking for.
There are a few options to chose from. At present I am suggesting this as a simple starting point:
First long of the cycle triggered by price >= 23.6% retrace of the down move; soft targets on each fib level (reducing 1/4 of the position with each touch of a new level).123if (not onMarket) and fibSet and (close < t236) thenBUY positionSize CONTRACTS AT t236 STOPendifIf the fib range is extended down after it’s first drawn (as per your example above) no trade is likely to be triggered. The probability of further retracement is much increased if 23.6% level is actually hit.
On the event of a false break of 23.6% the cycle is negated if the probability of break even on the first trade is reduced to below x% – need a hit rate and risk:reward analysis to set sensible stop loss criteria. Contemplating a degree of martingale style (“grid”) retries up to a degree of tolerance if probability of upturn increases – to be researched (Remember this should not yet be adapted to any one market’s idiosyncratic behavior – that will come much later).
To my mind we identify possible setups and their possible outcome scenarios. From there we identify what set of entry and exit rules would work the best (mathematically speaking) and using hindsight. Many “trading systems” employ one rigid set of entry and exit rules. What I propose is that the library (albeit top-down code) contain a sub-loop of entry and exit rule combinations (sub strategies). The intelligent piece will be to allocate a given sub-strategy based upon what’s happening with price action. This is how you would trade as a human. Furthermore oftentimes trading sytems stop “monitoring” price action as soon as a trade goes on :
12345678if not onMarket then// do some analysis of price actionendifif longOnMarket then// do some maths about our position// forget about anything that's going on with price actionendifThe former is as if you were closing your eyes and going to sleep immediately after placing at trade (You may as well have bought a binary option). Sometimes that is what you need. But I propose something like this:
1234567891011121314151617181920if not onMarket then// analyse price action// allocate an entry and exit system from several to chose fromendifif longOnMarket thenif strategy1 then// test against strategy 1 conditionsendifif strategy2 then// test against strategy2 conditionsendif// re-analyse price action// ...if (priceActionCondition) then// switch to a different strategyXcurrentStrategy = 3endifendifThis nested approach is a step closer to “inteligence” and more closely models the decision making of a human trader. One may argue that this models a “second guess” mentality but it may be worth being more dynamic in certain cases. We “trade what we see”. Think about possible price action scenarios post setup and what we can learn from hindsight. Also think about the indicator itself and how “sensitive” it should be in finding a valid setup?
ps: Not received any pull request off GitHub? Will take another look.
11/29/2016 at 11:38 AM #17462boilerplate for concept work:
https://github.com/publicprtcode/Backtests/blob/master/autofib/FibRetrace(long)-boiler-0.01a- Indicator includes pre-compiled*
- Ignore equity curve.
- No money management segment yet
*So PRT and it’s awful bugs: You can’t “CALL” AutoFib indicator because the resulting outputs of the indicator will be out of sync with the backtest code. You MUST currently compile the indicators into the back-test code in order to get the proper results. Any questions please let me know.
11/29/2016 at 12:36 PM #17469Contemplating a degree of martingale style (“grid”) retries up to a degree of tolerance if probability of upturn increases – to be researched (Remember this should not yet be adapted to any one market’s idiosyncratic behavior – that will come much later).
Was thinking the same this morning, seems effectively relevant when you look closely at how the price retrace through the Fibonacci levels when it has extended down beforehand, grid trading is always a dead-end somehow, but binomial probabilities would help in this case. You are right, this can come much later.. However, this is the *easy* solution IMO.
Just made the pull request FYI.
I had a quick look on your strategy code (not tested yet), I’m sorry but partial close of position is still not supported by ProOrder .. We have to find another way to deal with orders!
11/29/2016 at 1:43 PM #17477Good points.
On a slight tangent, I’ve been researching on averaging down systems for a long time so I’m fully aware of the risks, limitations and capital requirements. In some cases it’s lazy, in other cases it’s correct. Risk is the common denominator. The attached screenshot shows 2 back-tests of systems that I actually have in a live production environment (not PRT). They are both complex grid systems. The production versions yield better results than the below backrests as the propitiatory algo execution framework which they run on does not suffer any of the limitations of PRT / ProOrder etc.
So with regards to the inability to close positions partially in the live environment – it’s not a problem for real world application – it can all be achieved, just not on PRT; hence my emphasis on the term “backtest”. But in the meantime as you say yes there are some “hacks” you can do to get around that problem. There are also more strategy possibilities in relation to the fib system that don’t need partial closes.
Looking forward to your ideas. Also, are you able to reach out to other active members here and invite them to collaborate?
11/29/2016 at 1:57 PM #17480Just a bit of QA / QC Audit work … my ‘small beer update’ is still not showing in the latest version Master autofib_long-0.12 a.itf. (Nor even showing in autofib_long-0.1a.itf which I merged 1 commit into).
I had an option to ‘Auto-Merge with Master’ and so I did that (as you can see from attached screenshot) but clearly a ‘Pull Request’ is the only way to effect a change in the ‘Base Master’. I would have thought there would be only one Master?
GitHub does the back-office stuff well, but in my opinion the user facing controls & instructions leave a lot to be desired. However, it is almost intuitive so it’s best to ‘suck it and see’.
Above may help to assist others reading this Thread who are new to GitHub (and feel best not to drag you ‘big boys’ away from your excellent coding work!).
We need to get more accomplished coders on board?
GraHal / TraderGra
11/29/2016 at 2:50 PM #17485About averaging down, I spent too much time myself too on this risky business.
For Fibonacci retracement, another way to calculate them could be within this other topic idea I’m currently working on: http://www.prorealcode.com/topic/help-with-code-for-this-swing-trade-setup/
The concept is almost the same and have sense, may I can say more than your initial idea? 🙂 Using pivot points *real* key reversal is maybe more relevant than feeding the formula with the highest high met above the MA20 (100%) and same as for the lowest level (0%).
About inviting other coders here, well everyone is accepted on board, if you read this topic and got ideas (or any suggestions), don’t be shy and post them! 🙂
11/29/2016 at 4:11 PM #17487GraHal / TraderGra – I don’t see any pull request from you, just from Nicolas. I only see your comment, your fork and then one edited line. Not sure what you did exactly. I agree on your comments about the interface (lol) and housekeeping.
Nicolas – It’s worth trying all possible options and learning the probabilities of all. Will play; looking forward to your edits. In the same way that the system can dynamically chose from a multitude of entry and exit strategies (my post above) we might also chose from a variety of high-low detection strategies. Fractal detection (as user CEO76 illustrated in the above post), key levels and pivots are certainly criteria that can be integrated as available tools.
To my mind the ideal indicator might “choose for itself” which high/low criteria to select based on market conditions and the highest probability combination. This requires manual probability analysis first, starting with a rigid indicator and eventually moving towards machine learning of probabilities as they change with time – at a more advanced stage.
11/29/2016 at 7:26 PM #17511Hi Nicolas, thank you for your pull on “PRC_AutoFib PivotHiLo”. Nice idea to try, does it work? Here is my feedback:
– Thanks for renaming ma20 to maSlow (I was lazy :+1: )
– I see what you’re doing on the hypothesised fib bottom approach. Interesting idea; Not yet agreed upon estimating a 0% low below actual current swing-low price level; you’ve done it based on a previous swing low support from previous lows. See my screen shot. If market forms an uptrend then it appears that the previous swing low bottom is no longer significant as a fib bottom – the price respects fib from most recent swing low to most recent swing high more. (is that making sense – see my graphic in forum which should illustrate the point better)
– Also please do comment your source re Pivot calculator etcCheers!
11/30/2016 at 2:29 AM #17528Sorry ignore my point about fib bottom. I realized this was not you but a bug. I have fixed this in your update version and mine.
I have an updated version now which includes the following:
- Swing Low indicator for computation of sensible support level and fib bottom levels
- More sensitive indicator now finds more setups, controlled with minimum drop distance parameter
Attached are outputs from swingLow-0.1a and updated autofib indicator version 0.21a
https://github.com/publicprtcode/Indicators/blob/master/autofib/autofib_long-0.21%20a.itf
https://github.com/publicprtcode/Indicators/blob/master/autofib/swingLow-0.1a.itfHow is this looking so far – what can be improved next before we go into the topic of dynamic settings?
11/30/2016 at 10:23 AM #17533About the lowest low that piercing its already given information, the rsi-pop is a good idea, but the “old” Relative Strength Index is maybe not the better version because it is leaving too soon its oversold level and so give often false information about the fact that the price is trending, not returning to its mean so I encourage you to look at this new RSI version, the SRSI (Slow Relative Strength Index) that give me good results in my own development so far. Maybe the oversold level could be also adapted to this new indicator behaviour.. the signal of the lowest low may also be given a little late, but without many false signals because of the actual trend strength.
May I ask you to make the code for it? I’m always near to this post, but got other many requests on other forums, thanks.
1 user thanked author for this post.
11/30/2016 at 3:05 PM #17568Latest version with SRSI / RSI-Pop option
https://github.com/publicprtcode/Indicators/blob/master/autofib/autofib_long-0.22.itfSRSI-Pop (too slow for this but could be useful for another application)
https://github.com/publicprtcode/Indicators/blob/master/autofib/srsi-pop-0.1.itf11/30/2016 at 3:47 PM #17579Thanks a lot for including SRSI. Here are my fresh thoughts about true and false signals given.
Good signals:
1/ Once the floor level is set, wait of the price to breach the 50% retracement level and set the stoploss @ 0% price level OR go on market if the trend (define by MA trend context is on our side)
2/ Manage breakeven when price reach another upper level (define it dynamically according to market, next job..)
3/ Let the profit run with the trend / exit with trend change (MA cross) or opposite signal maybe?
False signals: (if the price go further low than the calculated floor)
Usually the trade will not be triggered because of the 50% test (point 1/ above), if it is the case, stoploss will occur. POINT. 🙂
11/30/2016 at 7:06 PM #17608Yep, something like that – it’s all about the research.
2 things to keep in mind
- We try to keep this market independent
- Each setup is unique to all before it
It comes down to creating a template of probabilities from which you can deduce if 23% or 50% are best for a first entry. Hit rate and potential risk:reward probability analysis will show some clues. Initially (see boilerplate) I was thinking first trade to be triggered on a break of a particular fib level – 23.6% for example but there are a lot of entry signals to chose from, not just the fib itself. There is always the question of whether the fib should just be the exit guide or not. Research will show if it’s worth programming the bot to “choose” this first trade fib level dynamically for itself based on price action and conditions prior to the “drop”. This means categorizing each drop into a pattern category and assigning an entry strategy to that pattern. There is also the question of where to exit and in what quantities. Also do we try averaging up? averaging down? Do we include CAM levels and pivot points, etc etc and the list goes on – 12 months later you have a production system… maybe! 🙂
Does the indicator give all we want yet? Before we bounce around trading system ideas?
-
AuthorPosts