Buy when price goes up, sell when price goes down…

Forums ProRealTime English forum General trading discussions Buy when price goes up, sell when price goes down…

This topic contains 13 replies, has 6 voices, and was last updated by avatar GraHal 1 year, 7 months ago.

Currently, there are 0 users and 1 guest visiting this topic.
View all attachments
Viewing 14 posts - 1 through 14 (of 14 total)
  • #74337

    Hi all,

    I would like to share my work on what should be a simple strategy to gain profit in market, in particular forex.

    Let’s start from this statement:

    Buy when prices are moving up. Buy each retrace/dip. Keep buying until the last retrace becomes a trend change which is the one trade you lose on.

    Sell when prices are moving down. Sell each retrace/rally. Keep selling until the last retrace becomes a trend change which is the second trade you lose on.

     

    Looks easy isn’t it?

    Why forex? Because currencies pairs cannot go to zero, neither raise to the moon, they must stay in ranges determined by central banks politics, government actions etc. They trend for days or weeks, giving multiple opportunities to enter.

    First of all, we must be able to identify if there is a trend. Due to the lack of mtf on PRT, I used a little trick. I use RSIOMA  (https://www.prorealcode.com/prorealtime-indicators/rsioma-indicator/) with a multiplier for higher timeframe.

    Example:

    where “tfx” is a round number thet gives me an higher tf rsioma on my tf. f.e. if I am on a 1H chart, tfx=24 give rsioma of daily tf.

    with these conditions I can determine if overall trend is bullish or bearish.

     

    Now, I wanna get an entry signal in the direction of bigger trend. This is where we can speculate the most (rsi, adx, moving averages crossover…) but I personally pick Leo’s moving average (https://www.prorealcode.com/prorealtime-indicators/leo-moving-average-supportresistance/) because, according to his own words “it is an indicator that do not move so quickly as the Hull Moving Average but no lagging like exponential or weighted moving average”.

    This is the base for developing a strategy (or strategies) discussion:

    Would like to have feedbacks and ideas about it.

    Thanks!

    Attachments:
    1. leorsioma.itf
    #74345

    Well it can do what you set out to do and on Indices! 🙂

    If you have 200k bars then adjust the settings on the itf?

    It runs soooo so quick, it’s a pleasure to optimise!! 🙂

    Great Work Alex
    GraHal

     

     

    Attachments:
    1. AlexF-TrendFriend-DAX-15M-v1.0.itf
    #74367

    I’m running the code below in Demo and it keeps getting stopped due to insufficient history.

    The biggest numbers of bars I can see required is 21 x 240 = 5040 so I’ve set preload bars at 5500.

    I have tried preload bars at 7000 and 15000 and it got stopped each time.

    Is there a maximum number of preload bars does anybody know please??

    Anybody any ideas why  the System is being stopped due to not enough History when I have tried 5500, 7000 and 15000  preload bars and System is stopped each time??

    PS / Edit  was just stopped again at 5500 preload bars!
    I’m going to try 30000 preload now!!!!

     

     

    #74398

    Stopped again even with 30000 preload bars.

    Shouldn’t this Topic be on the ProOrder Support Forum as it is discussing code issues?

    PS / Edit

    I’ve sent a Technical Report to PRT.

    #74402

    Not sure but i think i read something about preload bars and that there is a limit of how many you can use?

    maybe Nicolas knows?

    1 user thanked author for this post.
    #74410

    In line 5 MA                 is calculated with 3360 (14 * 240) periods.

    In line 6 RSIOMA       is calculated with 3360 (14 * 240) periods of the MA calculated with 3360 periods!

    In line 7 MARSIOMA is calculated with 5040 (21 * 240) periods of the RSIOMA calculated with 3360 that had been calculated with MA calculated on 3360 periods!!

    I’m  afraid they need to be internally multiplied, hence… no way to run it!!!!!

     

    #74422
    Thank You Roberto

    I’m  afraid they need to be internally multiplied, hence… no way to run it!!!!!

    So the code is flawed then?

    Can you / anybody  suggest any way to write Line 5, 6 and 7 so it will run please?  What do you mean internally multiplied??

    I had already tried below and it got rejected … as expected due to Roberto obsevations.

     

     

    #74427

    Aha do you mean like this …

     

    #74428

    No above is no good … rejected again, same reason … not enough historical data.

    #74431

    No GraHal, I meant internally they will probably need to multiply 3360 * 3360 * 5040 = ….. billion bars!

    Should PRT answer giving different reasons, please let us know.

    1 user thanked author for this post.
    #74433

    Maximum preloadbars is 10 thousands bars (10.000). So, even if you set more than this limit, the maximum bars loaded by ProOrder will always be 10k.

    2 users thanked author for this post.
    #74435

    Apart from platform limitations, I don’t see useful using a daily trend for 15M f.e.

    I personally don’t go over 2 superior timeframes.

     

    By the way GraHal, try to remove marsioma from code and use only rsioma’s slope for trend. This should reduce number of bars for computation.

    #74436

    That’s the way I simulate mtf in my codes (although with diffrent multipliers and not rsi but that’s not the point). Grahal with those sets of 14 21 and 240 values, it’s almost as Roberto said, except you’dd add rather than multiply: here you’d need a full first set of 3360 bars before being able to have ma for the first time (before that it doesn’t exist), then from bar 3360 it takes another set of 3360 to have your first rsioma calculated on ma, that’s 6720 (should be 6719 because starting from 3360 rather than 3361 but let’s not get hung up on that), and only from then would you start counting the 21tfx=5040 to get your first marsioma, so that’s 6720+5040=11760 (well, more accurately 11758). And you’re above the 10k magic number, but not by much, so doesn’t have to be forgotten completely, just adapted to a bit less as long as you’d be happy with less.

    As a side point, even if not relevant here and now but you might bump into the problem later on, another one to take into account when simulating mtf in such way you’re borderline with limits, it is the total history available in the chosen timeframe of your instrument… you may have your 10k bars available in a smallish timeframe, and use multipliers that keep you below 10k, but when trying it in a bigger timeframe, like (x) days or weekly, IG might not have a long enough history to get your first higher timeframe simulated value, regardless of the preloadbars set to max. For later on, just in case…

    Switching off for world cup now, and going on holidays. Enjoy your summer guys.

    3 users thanked author for this post.
    #74442

    Ha it worked @Noobywan … have a well earned holiday! 🙂

    Thank You
    GraHal

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