Need help to code a more dynamic trailing stop

Forums ProRealTime English forum ProOrder support Need help to code a more dynamic trailing stop

  • This topic has 13 replies, 6 voices, and was last updated 6 years ago by avatarLeo.
Viewing 14 posts - 1 through 14 (of 14 total)
  • #59923

    Hi guys. Im wondering if someone would be willing to help me code this idea.

    So the thought is that the closer i get to the target, the tighter the stop loss would get.

    Say i have a 100 pip target, i would like the trailing stop to begin after 40 pips profit, and then start off with a 70 pip trailing stop loss, but if i move 10 pips closer the trailing would become a 50 pip trailing stop loss.

    If im 90 pips in profit the trailing would become 20 pip trailing stop loss.

    Does that make sense? Im pretty sure its possible to code, im just not sure how.

     

    Edit: the numbers are just as an example. The thought is to either code it so it calculates how many % away from the target you are, and  say if your 80% to target, then it would move the stop loss to 20% away or something like that.

    Another idea is to just code levels like “if 50 pips in profit then use trailing stop A.” and then “if 70 pips in profit the use use trailing stop B” and so forth. is that possible?

     

    I would guess a more advanced MFE trailing stop i guess.

    #59970
    AVT

    My MT code does the following:

    • set MinProfit (in Euro): the amount of profit when to start trailing
    • set TrailingStop (in points 60 is good for division): the initial trailing stop to be set -Bid/+Ask
    • trailing loop: for (i=1; i<=6; i++) { if (OrderProfit()> i*MinProfit) TS=TrailingStop/i ;
    • and then if OrderStopLoss() < or > TS OrderModify to the new TS

     

    This sets the TS into the same relation as the profit. I like the 60 because it divides without destroying the Digits – and 6 times is in m5 enough to get thrown out (yep, happens). Should be possible to do the same in PRT.

    1 user thanked author for this post.
    #60054

    Best to quantify what effect these ever tightening stops have on total return on system imo  .  Just a suggestion , sorry

    #60055

    @brisvegas Your right about that! I think i could save alot on tightening the stop loss accordingly, but until i get my hands on a working code its hard to say wether or not this is good for the total profit vs total loss. It might fuck up your whole system, but speaking for my own systems i think it would be more useful for the ones that have a shorter target then the ones that try to ride the entire 400 pip trend hehe.

    #60120
    Leo

    Hi, I use a lot this kind of concept because many times when I add a target profit, the price revere just a couple of pips before… I know ion this forum that happened so many times that I start to think about that conspiracy theory.. anyway.

    Here is my code:

    I have a target (AIM) and a stoploss (start) in pips, then I use a Moving Average with I name “guide” .

    I measure a value from 0 to 1 where the “guide” is between the “start” and “Aim”. I called “ZONE”

    With that coefficient you can do whatever you want for example I have an exit condition for long

    Here the code:

     

    Pleas tell us if it is useful.

     

    #60122
    Leo

    sorry, AIM and START values are the price. not pips

    #60125

    @Leo, thanks man! And yes, the famous “price reverting right before your target” is insane 😀 And also some of the reason that i want a better trailing stop.

     

    I, not sure if i understand the code tho. Let me see if i get it right:

    When trade starts, a “zone” is created, where 0 = entry and 1 = target. And then you use a moving average (how?) to meassure how many % away from the target you are?

    Is it possible for you to dumb it down for me? 😀

     

    I have been playing with the MFE trailing stop loss, adding “levels”, but it hasnt really worked out that great for me, again i feel like its too “static”. Needs to be more dynamic, probbably using some sort of filter, like volatility or something. Not sure. Adding code where i added 1 level. It seems to be working when im looking at trade log from backtest.

     

    #60359
    Leo

    Hi Jebu89,

    You have a price for a reference, for me I use a moving average like SMA20=average[20](close)

    Then you have a value “ZONE” between 0 and 1, where 1 if the value SMA20 is at the “start” level (for me is the stoploss level) and 1 if the value SMA20 is at “AIM” level… in practice the value ZONE is always around 0.2 and 0.8 because if the ZONE is near to 1 is very likely that the stop loss was triggered,  or if zone is near to 0 maybe the trade was already close with profit.

    why like this because I add a condition like this: close position if ” close < lowest[ round(zone*period) ]( close[1] ) ”

    Have a nice day!

    #61167

    I have developed a slightly different approach that works well for me so far.

    I attempt to calculate a very accurate ATR right before opening a new position using something like this:

    Then using this ATR value I calculate the following levels once at open using WF optimization:

    1. Target i.e. 10*ATR
    2. Trailing Initiate i.e. 6*ATR
    3. Stop i.e. 5*ATR

    Only once a close beyond the Trailing Initiate level is registered I start trailing. Here is a example of how I do it:

     

    2 users thanked author for this post.
    #61169

    Juanj – I am a little confused (maybe it is just too early!) by why the MAX(1,10) is in the ATR calculation as it will always return 10.

    Otherwise I think I see what you are doing is to use a super-smoothed ATR (I guess to remove spikes that could result in very extreme positions) to calculate initial Target, Profit  and Trailing Start levels and then once the trailing start is triggered closing at a 40% fall back of the difference between the biggest MFE since the trade was opened and the opening price of the trade.

    I’ll try it out if I get some time.

    #61170

    Yeah sorry that was a copy/paste from code I used.

    It was originally average[max(1,barindex)](((AverageTrueRange[5](close)[17])+(AverageTrueRange[5](close)[12])+(AverageTrueRange[8](close)[2]))/3)

    Obviously at some point changed it, but didn’t want to remove it altogether.

    #61174

    Obviously at some point changed it, but didn’t want to remove it altogether.

    That explains it – I do the same all the time as I think I might want to add things back in at some time in the future and it would save me 2 seconds of typing! In reality the mess of //,s and code that should not be there loses me more time scrolling up and down than if I’d deleted and retyped later….. but I still do it!

    1 user thanked author for this post.
    #61175

    Version 1 was actually just;

     

    #61230
    Leo

    I have developed a slightly different approach that works well for me so far. I attempt to calculate a very accurate ATR right before opening a new position using something like this:

    Then using this ATR value I calculate the following levels once at open using WF optimization:

    1. Target i.e. 10*ATR
    2. Trailing Initiate i.e. 6*ATR
    3. Stop i.e. 5*ATR

    Only once a close beyond the Trailing Initiate level is registered I start trailing. Here is a example of how I do it:

    I like this approach,

    when I need to set distances with ATr I use this, maybe is useful for you as well

    P is a period, k1 is a number between 1 and 3

Viewing 14 posts - 1 through 14 (of 14 total)

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