Machine Learning in ProOrder ProRealTime

Forums ProRealTime English forum ProOrder support Machine Learning in ProOrder ProRealTime

Viewing 15 posts - 16 through 30 (of 455 total)
  • #121071

    @juanj Thanks a lot for sharing this!

    I’am testing it live on a strategy , 1 sec, stoploss 0.1%, market orders and to make it simple I have long only.

    One thing to make sure, while optimising for 200k for a few days, that it’s reset on daily basis. Did I have this (init) right?

     

     

    #121072

    a pic in action, don’t mind the results a.t.m. got it working!

     

    #121077

    @Paul I prefer keeping the output variable as ValueX and rather assign the target variable to ValueX (i.e. after the algorithm just set boxsize = ValueX)

    Also remember ‘day ‘only goes up to 28-31 (depending on the month) and then starts again at 1 from the next month. So perhaps rather try this:

     

     

    1 user thanked author for this post.
    #121081

    Thanks a lot, as always it’s way more complicated then I thought!  I’ve included this and got it working.

    I really think your code can be a game changer. Will let you know how it goes after I’ve spent more time on this!

    #121082

    Could this be applied to more then a value in the same system?

    #121090

    Depends on what you mean.

    If it is the same target variable just used in different sections of the code then yes else no.

    The reason being that if you apply it to 2 or more different variables the algorithm will not be able to tell which one is causing the performance increase or decrease.

    I have experimented with literally duplicating the algorithm (slightly changing the name of each variable in the algorithm) and assigning it’s output to a second variable.

    And although this works to some extent it definitely reduces the accuracy and efficacy of the algorithm for the same reasons mentioned above.

    1 user thanked author for this post.
    #121101

    Yes I was talking about implementing machine learning on all the entry and exit variables of a system; in order to have a fully automated system that can evolve and change simultaneously with the evolution of the markets without needing human intervention.

    #121113

    You would need it to analyse every possible combination of variables as each combination of them is what has to be checked for best performance. With the arrays now in v11 this might be possible. If for example you had three variables then you could set $a[1], $b[1] and $c[1] to your first combination (10,10,10) and $a[1], $b[1] and $c[1] to your second combination (10,10,20) and so on. Then check each set for performance.

    #121114

    @Vonasi exactly! Looking forward to implementing arrays to the algorithm.

    Only problem we will still have is that with multiple combinations of variables we will need much more data to determine what works (or don’t work).

    #121116

    Yes – the more variables the more possibility of curve fit and it doesn’t matter if it is us or our strategy that is doing the curve fitting! That was my experience when playing with the concept anyway. Perhaps as something that just tweaks a variable value to improve strategy performance slightly the concept might work but I think that expecting it to create a strategy from a massive quantity of values and variables is a little unlikely with the computing power that we have at our finger tips.

    #121123

    I have experimented with literally duplicating the algorithm (slightly changing the name of each variable in the algorithm) and assigning it’s output to a second variable.

    And although this works to some extent it definitely reduces the accuracy and efficacy of the algorithm for the same reasons mentioned above.

    Did you try having algo v1 running / optimising on (for example) even number barindex and algo v2 running / optimising on odd number barindex?

    Algo v1 and v2 running / optimising on different bars would prevent the algos confusing each other?

    #121125

    Hi Grahal, since the algorithm does not base it’s ‘optimization’ on time (i.e. bars) that wouldn’t make sense.

    Although what could work is if you allow the two algorithms to take turns in making optimizations.

    In other words each algo get x amounts of trades to analyze and make adjustments

     

    #121126

    allow the two algorithms to take turns in making optimizations.

    Above is what I was proposing … 2 Algos in the strategy with 1 algo only optimising on each alternate bar.

    Might you post the duplicate algo please with the changed variable names … I’d like  to try my idea.

    I did try using ValueX and ValueY, but of course there are other variables part of / common to both algos.

    I am getting good results even with 1 algo … can’t believe your self-aware Opti Algo has been overlooked by us all for nearly 2.5 years!

    It kinda feels like the most exciting that has happened for a long while!

    Thank you so much for sharing juanj.

     

    #121127
    1. If the algo uses the past x number of trades to optimise against … why is there a need to reset optimisation after y months?

    Surely the self-optimisation is ongoing on a self improving basis?

    Resetting after Y months would defeat the optimisation against recent results??

    2. Does the algo increment through all prescribed values at each optimisation  (against the last x trades)?

    #121129

    @GraHal to answer your questions:

    1. There is ‘theoretically’ no need to reset, I have merely included the option to ‘start fresh’ every quarter/year etc. in the event that optimization perhaps went wrong
    2. Not sure if I understand you correctly but after the evaluation period  (Reps) only a single increment is made either up or down depending on which appears to improve performance more.

    Here is the version of the algo outputting ‘ValueY’  (Remember the performance evaluation of each algo is only done after the amount of trades (specified as Reps) and will therefore not be useful using an alternate bar optimization method. Best is to code it so that each algo gets it’s own evaluation period. Although it would require at least 2 evaluation periods to really know if performance is increasing or decreasing. So perhaps an additional ‘wait counter’ should be built into the startegy giving each also 2 or more evaluation periods before giving the next algo a turn.

     

    3 users thanked author for this post.
Viewing 15 posts - 16 through 30 (of 455 total)

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