Increase number of position based on 30 tic moves

Forums ProRealTime English forum ProOrder support Increase number of position based on 30 tic moves

Viewing 15 posts - 1 through 15 (of 16 total)
  • #35350

    Hi, I have looked in these forums for a simple method to increase the number of positions up to a maximum of three, based on successive 30 tic moves in the direction of the trend.

    As a discretionary forex trader I would wait for sharp up/down moves in the tick on a 10 min chart and enter with the direction of the move (better to be on the right side of the 2 day trend) adding to the position. I found three positions as much as you would want to handle particularly if volatility increased sharply (fast market). I wanted to see if it worked using a trend filter like the Ehler’s Supersmoother Oscillator before looking at Momentum (proceeds price) indicators indicators and also adding an exit for closing all three positions together during sharp adverse moves.

    Based on the forum posts I have the code so far as:

    c1 is a long trade based on the Ehler’s Universal Supersmoother Oscillator (found in the PRT indicator section in this forum) crossing over the -0.8 threshold. Yet it won’t take the second and third positions?

    Any ideas what I need to add to the code?

    The backtest was conducted on the Daily Dow DFB, initially on year 1990. Results were okay with Universal Osc bandedge = 25 and a spread of 3.8 and were left untouched on further date expansion: 1990-1991 and 1990-1992. The Choppiness Indicator that Randy Stuckey used for Catscan IV will stop positions being taken in choppy sideways markets which in non mean reverting systems will lead to losses. The drawdown is still high at 32% which will typically translate into 50% more drawdown when live. This is not a system yet. Different markets tend to have different bandedges. Note: Randy Stuckey used different choppiness index thresholds for each market.

    As a further point I noticed whilst looking into position sizing code that there was a lot of discussion on “averaging down trades.” From previous trading experience I would not recommend this “tempting” method to mitigate losses because although it works in many instances and will “save your bacon,” there will always be very large fast adverse moves that will cause problems… like when some idiot at the Fed makes an unexpected and unannounced policy comment on a Bloomberg radio show…

    It’s also worth checking out the pyramiding style of Ed Seykota’s hero, Amos Hostetter.

     

     

    Thanks
    Bard

    #35415

    Your code doesn’t take cumulative orders because of this particular line:

    Copy and replace it in your code to get extra positions according to your strategy.

    #35474

    Hi Baird

    I’d like to run this Bot please, where can I get Ehler’s Univ Osc SuperSmoother?

    Thank You
    GraHal

     

    #35496

    Hi Grahal,

    It’s here: https://www.prorealcode.com/prorealtime-indicators/universal-oscillator-john-ehlers/

    A bandedge for Daily charts or 25 is okay.
    For 4 hour, 75 is good on currency pairs and indices,
    I have used a 100 but it’ll stay over bought/sold for long periods, it depends on the volatility to some degree eg Nikkei’s versus FTSE versus GBP/USD.

    The cut off thresholds that work well are:
    Buy if Univ Osc crosses over -0.8 or -0.9 and Sell if it crosses under 0.8 or 0.9. You can also add thresholds for exit Long and Shorts. Sometimes just using the zero line as intended, works for entry and exits (no exit longs and exit shorts).

    What you will find is that on backtest for a set period of time like 1 to 2 years on a daily chart or 6 month to a year on 4 hour charts, it’ll work amazingly well but then on the next test period it won’t, inferring that the cycle period has changed (I think this is the bandedge setting). I tend to optimise on one market and then “let it loose” on a non correlated market to test it’s robustness.

    Funnily enough I’ve drafted an email to John Ehler yesterday to see if he had any solution to this changing bandedge issue (like maybe having a Cynthia Kase’s Peak Oscillator style code that allows it to optimise over 50 different cycle lengths (hint if you see this @Nicolas, lol), the idea being that it checks different look back lengths for the best cycle length). I’ll send it after they have replied to my inquiry about the MESA ES leader-follower : http://www.mesasoftware.com/ehlers_leaderfollower.htm

    I expect he’ll say use the MESA Period indicator (also coded by Nicolas in this forum) but even if MESA period indicator suggests a cycle period of say, 23, why you apply that value to the bandedge in the Oscillator it doesn’t necessarily improve it’s performance. Maybe you can figure that out because MESA period should be a useful value to input into bandedge unless I have misunderstood bandedge? Logarithmic indicators make far more sense than linear ones.

    #35512

    Thanks Nicolas,

    I did have cumulate orders = True, when working on other attempts of trying to get this three entry system code to work..
    I always thought that by setting it to: True, that as long as the entry code conditions prevailed and the original entry conditions were still in effect it would take multiple positions? i.e. if the oscillator was set to sell when it was e.g. a less than condition like: < 0.8, then whilst that “less than” condition prevailed lots of trades would occur with cumulate orders set to True. However with a “cross under” condition surely that typically is a “one off event” and so you’d just get a single entry? Therefore the new entries for //second order and //third order are new specific instructions and therefore wouldn’t need a cumulate orders = True setting?

    When I do set the code above to cumulate orders = True, it doesn’t work as I intended because it takes 7 short positions!? i.e., after the initial opening position it’s taken 2 positions on 3 separate days. (pls see screenshots). I specifically want it to only take a new position after exactly 30 tics and then if another 30 tics have occurred, to take a last third final position. Eg Sell at 1.6300, then again at 1.5970 and lastly at 1.5940. How would I code that?

    Clearly the issue is that it’s dependent upon whatever the opening price is available for the next candle (second order)…. so in the case of the first trade it shorts at 1.6328 and the second trade is taken at 1.6268 etc.. It looks like cumulate orders set to True has doubled up the the second position so it enters two trades and not one because it is set to true, right, which is why I  left it off thinking it would just take 1 position for the second order and one for the third order?

    Cheers
    Bard

     

    #35526

    Yes, if your conditions are still true, it will continuously open new order. So you have to prevent it by adding condition to count quantity of opened orders actually on market or if you are already ONMARKET or not…

    #35915

    Thanks Nicolas, I recoded it to take a maximum of 3 positions at a time, with a count of positions code – incorrectly it would seem, lol – as it took 4 positions at one point. the code is below – it is slightly more profitable without the Chop Index.

    I left the cumulate orders on as it would not take any more than one position when set to False? Not sure if that is correct.

    As I said it took 4 long or short positions (instead of the maximum of 3) at one point during tests on the Daily £/$ DFB 1990 – 1996… I’d share a screen shot but the MESA indicators are continually loading over and over again on v10.3 so it’s set to 25 units currently, (I have posted in the forums about that MESA reload issue which never occurred on v10.2).

    The code is optimised by hand for the 0.3 crossover (having tried 0.0, 0.1 and 0.2 thresholds to stop whipsawing).
    I don’t really consider it a “system” but I suppose it could be, judging by how simple some of the early automated strategies were in Krutsinger’s Trading Systems book. Clearly the less parameters a system has the more likely it will work in the future and not be subject to over optimisation or unintentional curve fitting.

    It was tested from 1990-1991, then adding one year at a time (all positive % gains and drawdown around the 37% mark and a gain of over 1000% for the 1990-1996 period). I stopped at 1990-1996 because from experience I know that it’ll produce a loss with one “rogue trade” as the bandedge or the crossover thresholds end up needing to be changed.

    I did try it on the 2000-2002 period and it fails because the bandedge is currently set to 25 in this example (1990’s) but needs to be 100 for the 2000-2002 period (Drawdown 27%, 96% gain).

    Can bandedge be optimsised if the Oscillator code can be added in with the system code? That way an Excel, bandedge versus profit graph could be drawn to find a stable range for the bandedge that will make it more robust.

    “Ehler’s Oscillator to take 3 positions maximum”

     


    @Nicolas
    did you ever come up with a way of finding the best way to determine the bandedge for this oscillator or is it always going to be subject to needing adjustment (which makes automating it hard)?

    Perhaps the MESA Trendline and Kalman will need to be used to determine if the market is in trend mode or cycling and then the system can be coded to switch modes and use zero line crossovers for trending and 20/80% thresholds for cycling. But what bandedge to use overall…? That needs testing.

    As you said previously the results are (at times) “stunning.” (-:

    Cheers
    Bard

    #35925

    Your conditions at line 11 and 42 are there for the first order, right? You should test there if you are already longonmarket / or / shortonmarket or not before, I think that’s the reason you get more than 3 trades.

    At lines 24 and 29 you are pyramiding the long orders, the calculation are correct. This is not the case at lines 55 and 60 for your short orders, because you add more even if the spread between the current Close and your last trade is inferior to 30 points or 60 points!

    You can of course optimise the bandedge of the indicator like you could make for any other one. You should put the code into the strategy to gain times in the optimisation process.

    1 user thanked author for this post.
    #41706

    Hi Nicolas, I got the time to have another look at this Ehler’s Oscillator system where it increases the number of trades based on an increase at least of 30 tics before the second trade is taken (ditto for the third and final trade). However looking at it it’s trade results with the Short side code altered at line 50 and 60 (< condition changed to > as you suggested) it still doesn’t take trades correctly.

    Trading the £/$ 1 hour chart from the beginning of 2017 to now, I can still see second long trades taken when there has not been an increase of 30 tics (ditto with Short trades) and sometimes there are more than the maximum 3 trades being taken. In the screenshot attached there are over 3 short trades taken on the left of the chart and when the long trade is taken (approx in the middle of the chart), although the Oscillator condition remains intact (Oscillator indicator1 > -0.8) for a second and third trade, none are taken.

    What am i missing here?

    Cheers again,
    Bard

     

    #41717

    For SELLSHORT, you make wrong comparison between the tradeprice and the Close, the calculation you make give negative values, you should make the substraction like this instead:

    You should try also to GRAPH COUNTOFPOSITION, I’m not sure that 10 CONTRACTS = 1 POSITION !

    #41826

    Thanks Nicolas,

    I wondering if that might have been the case for the Short side, re: the order of the TRADEPRICE(1)Close>30.

    I added the countofposition graph – after removing buy or sell 10 contracts and using 10 perpoint – but it just mirrors the actual trade positions chart e.g. +10 or +20 (£10/tic or £20/tic)?
    Basically it’s not pyramiding as I intended it to which is clear from the buy and sell arrows on this chart attached, e.g. buying at a lower price than the original first trade:

    Cheers
    Bard

    #42425

    Hi Nicolas, how’s it going? I added the Not LongOnmarket (and ditto for the short side as per your suggestion #35925) but it will still not pyramid the positions to a maximum of 3 trades total, using a 30 tic increase per position. I even eliminated the Ehler’s Oscillator and used a simple 40 Mov Ave and 50 Mov Ave cross but it will not pyramid.

    Here’s the Mov Ave code version used on the £/$ 1 Hour 03/01/16 to 30/06/16 with a 3.8 tic spread:
    On the screen shot below the 40 and 50 Mvg Averages are the thick red (40) and blue (50) lines but there’s no pyramiding added to the original long position on the 2nd March although the close is >= than the 40MVG and the 40MVG > 50 MVG and +30 tics and +60 tics have been achieved?

    Any ideas?

    Cheers,
    Bard

     

    #42698

    Hi

    Can anyone figure out why the code to increase the number of positions up to a max of 3 positions (based on 30 tic increases per position) does not work?
    £/$ 1 Hour — 3.8 tic spread. Date: 01/01/17 to 01/06/17.

    I’ve simplified the system to the point where there are no other criteria for extra positions (#2 and #3) other than an increase of 30 tics from the last position taken. Exits Long and Short have also been removed as per the Moving Average version above.

    Thanks for any help,
    Bard

     

    #108415

    Hi Nicolas, I re-read through this thread and wondered what was the error in the code above (and it wasn’t the entry criteria as I simplified that) that failed to make this system simply take a maximum of 3 trades with 30 ticks increments between positions? (It would take more that the max 3 positions and with no respect to the 30 tick threshold before a new trade. Cheers!

    #108416

    Graph countofposition and all should become clear.

Viewing 15 posts - 1 through 15 (of 16 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login