WR% Lookback on 4hr TF printing last condition met.

Forums ProRealTime English forum ProBuilder support WR% Lookback on 4hr TF printing last condition met.

Viewing 15 posts - 1 through 15 (of 22 total)
  • #232746

    Hello All,

    Looking for a bit of feedback on WR% lookback. 4hr TF.

    I  put together a little bit of code (it’s very basic) and while it does look back well enough, it’ll ‘print’ the very first flavour of OB/S that it finds w/in the lookback period rather than the last one it’s seen that meets the OB/S criteria. Has annoyed me, won’t lie, because it’s a good example of my own short comings and how I landed in the ‘oh that worked’ zone for a few weeks now and have been going WOT printing all and sundry to screen, not quite but you know the gist …. 🙂

    Ideally the code could live in an auto-trader as part of metric-build-up.

    Roberto’s Cowabunga and Nonetheless’s template has been very good at steering the ship, so many thanks to both for the posts.

    I also see a bit of indifference when using ‘or Williams4h > -20″ / ‘or Williams4h < -80’ along with the above statements – they have no effect to the print. For example when then we have an OB scenario on 4h and the following criteria is met:

    there’s nothing printed when we have  Williams4h > -20 in there alone for example.

    All this lives on 5min TF chart and is a good basis for getting it across the line first.

    I guess what I was after was, that during the past  periods (any), say 10 periods (on a WR% 4hr) and the conditions are met, we print the last condition met through that period. Printing the last two conditions would be great too but I’d take the last!

    I’m using the following to clean up the remainder in the event conditions aren’t met. But if we could print the last two that could eliminate it maybe.

     

    Many thanks,

    inv

     

     

     

     

     

    1 user thanked author for this post.
    #232756

    This code seems to work as you expect:

    I just replaced OVER by UNDER in line 9, if that’s not what you want you may restore  OVER.

     

     

    1 user thanked author for this post.
    #232777

     

    Many thanks there Rob.

    I’m starting to wonder what’s going on, on my end *cough* …..

    Thanks for again for the help, it’s appreciated.

    I’ll have a look over it all and post back, no doubt it was a me thing.

     

    #232840

    Looking good over here Roberto. (apologies for not getting back sooner).

    Thanks for the assistance, you’ve sparked further creative thinking in other areas too  .. 🙂

    1 user thanked author for this post.
    #233084

    Hi Roberto,

    Just revisiting this one and all good on the summation front but I have a few questions.

    Is there a way to use something like following to determine when – prior conditions – existed. Could serve as a dynamic lookback variable of sorts or could be useful for a learner piecing together swings based on WR% (our intended use case).

    The initial summation does a great job but just wondering there’s another avenue to reference ‘historical’ events. Define the crossover/under a bit differently.

     

    For some reason I can’t seem to get my head around how to output the barrsince events to screen. I can ‘print’ them and wow, that was intense but I can’t reconcile w/in my mind how I can move forward from ‘returning’ them as an indicator to ‘drawtext’.

    The idea here is to drawtext and define not only the current OBS conditions but also the preceding historical condition based on what barrsince can determine. There’s an argument that once we know the current periods condition the previous would be the opposite but knowing that it is is much nicer.

    Thanks for your help.

     

     

     

     

    #233090

    Had another look and came up with the following, not sure tbh.

     

     

    Logic could be a bit bad on my part, aside my understanding in general and intended use of barssince may not be as I’ve employed it!

    Other thing is, when swinging between 1k bars and 5k bars the results are opposite.

    It’s very slow and another reason I tried lowering the bar count, as opposed to using defparam calculateonlastbars.

     

    #233094
    JS

    Hi,

    This is an example of how I indicate the different “Crossings” on the graph…

    (In this case, the “Crossings” between a fast and slow average)

    1 user thanked author for this post.
    #233115

    Thanks for sharing JS.

    I’ll poke about and see what I can put together but what you have there is in line with what I’m after, much cleaner and direct, addressing your data points nicely. Hopefully I can build something similar. I did look at Barindex as a point of reference and then went a little sideways around it …. long road over here!

    I think this is an area I’ll need to work on. I find I’m overthinking it in places and adding too much, perhaps also neglecting things as well.

    Thanks again.

     

    1 user thanked author for this post.
    avatar JS
    #233117
    JS

    Hi,

    It is indeed tricky… I don’t know if it’s of any use to you, but I’ve written down a few things that I think are important in PRT… reading is optional 😉

    ProRealCode is a relatively simple language to learn, but this simplicity is also the weak point of the language. The language has been made “simpler” by being less strict with certain procedures (e.g. not having to declare variables) but this also means that you immediately miss a certain structure in the code…

    I think it’s important to first understand the (basic) workings of the code, things like:

    A graph is loaded from left to right, bar by bar (candle by candle) and during this loading the code is executed after each bar (Close) up to the most recent bar/candle after which the code is executed during each new “tick”…

    The index (bar index) of the loaded data (OHLC) also runs from left to right (bar index starts “left” with 0) but when you want to refer to certain data, it happens from right to left (for example, the far right is Close[0])…

    The code roughly consists of three modules:

    ProScreener (screeners), ProBuilder (indicators) and ProBackTest/ProOrder (trading systems)…

    ProBuilder is the basis (calculations, drawings, colours, texts)

    ProOrder have a number of specific commands/instructions, for example buy and sell instructions, which cannot be used in ProScreener or ProBuilder…etc…

    Furthermore, I would structure your code a bit, for example:

    Defining the parameters => Input values for e.g. indicators => Conditions and calculations => Possibly MM => Buy/Sell instruction => Any trailing stops / stop loss / take profit

    2 users thanked author for this post.
    #233216

    Hi JS,

    Boy oh boy have you over simplified it above, trying not to scare me off …  🙂

    Have made a bit of progress (thankyou) and I’m starting to feel a bit dangerous (hehe), so looking to pre-can some of the figures for later use.

    I’m kicking and screaming all the way lol but will persevere for now.

    I have some triggers coded and they work okay but as I went on I started working on some inside/outside bits so I can define larger moves better and clean up the moves w/in – granular vs big picture – it’s coming along okay and I’m adding them to buy-sell conditions and printing to screen as I go – hopefully this might add value to an autotrader one day aside the training wheels for young and old. There’s just not enough hours in a day and market replays although great have you tweaking out of hours at x100 to find it all a bit slow in-hours and then you’re hunting around thinking it’s unwound itself – learning curves. Ha.

    For now I’m looking to see how I can store a number and use it a variable elsewhere.

    LLX below draws nicely just haven’t worked through using it …. I did read somewhere if you can store it you can use it as a variable anywhere (in an auto-trader too?)!

     

     

    Quick qu., what’s the line in the sand look like re: auto-trader. A quick poke about shows that anything that requires
    a retrospective go-over might be unsuitable aka what we discussed in the other thread (macd hh-ll stored in an array).

    Can for example what’s seen above (LLX), if stored in an array (single number or multiples) be called upon in an auto-trader setup for use as a summation lookback. Can it be stored in another manner perhaps? Just trying to get a feel for limitations before I start thinking or going to far only to realise most of what I’ve pre-canned is unsuitable for an auto-trader and although not the end of the world because it’s a guide first and foremost, a little bit of synergy goes a long way and for me it’s about middle ground so any feedback would be appreciated.

     

     

    #233260
    JS

    Hi @inverse,

    Totally simplified so as not to scare you off… 😉

    *The main ideas to know in the ProBuilder language are:

    1. It is not necessary to declare variables
    2. It is not necessary to type variables
    3. There is no difference between capital letters and small letters
    4. We use the same symbol “=” for mathematical equality and to attribute a value to a variable

    A variable in PRT can be compared to an “empty box” in which you put a certain value. The “box” has a certain name (e.g. “x”) and you use the symbol “=” to assign a value to the variable, for example x=10…

    *Documentation ProBuilder Fundamentals

    So, in your last code, for example, “LastCO” and “LastCU” and “LLX” are variables with a certain value. The values of the variables are determined by the conditions behind the “equal sign”…

    Variables are related to the “BarIndex” (the independent variable) and are thus historicized. You can find previous values by using brackets [ ] for example: x[3]

    Arrays are (special) variables that can contain more than one value at the same time, arrays are not related to the BarIndex and therefore not historicized BUT arrays use an “index (number)” with which you can recall a value for example: $x[3]… The number (integer) between the brackets is the index (place number) of the values searched for in the array list…

    Unless you keep it very simple, I wouldn’t recommend starting with arrays yet… keeping the indexing straight can drive you crazy… 😉

    1 user thanked author for this post.
    #233279

    @inverse

    line 5 of your last code reads:

    apparently to know how many lookback bars have elapsed to accomodate the two crossovers. If this was your goal, well… it’s not correct, as you can see from my attached pic X, for which I used this code:

    as adding the two values would return an incorrect value, just take note of the leftmost one of the two (the greatest value):

    and if you need to know how many bars have elapsed in between the two, subtract them (using ABS to always get positive results):

     

    1 user thanked author for this post.
    #233289

    Thankyou both.

    TBH, I’m finding many syntax errors on my part and basic lack of applicable knowledge (in addition to the errors above). It’s coming together and I thankyou for the responses.

    I’ve been able to print enough to screen which is great and as a POC I can manually adjust lookbacks to meet goals of sorts and POC that it works correctly (by  a manual count etc).

    What I was wanting to do was, was to use the value stored in LastCO80 (as printed to screen) and use it for a lookback period.

    Apologies for my awkwardness in how I approach things.

     

    #233291

    Looking back example:

    OS = summation[LookBack1](williams1h crosses under 80)

    Where lookback1 = LastCU80 and derived by:

    LastCU80=BarsSince(williams1h Crosses Under 80)

     

    Thanks for the help and guidance.

    1 user thanked author for this post.
    avatar JS
    #233315

    I’m sorry for not being clearer.

    What I would like to do is, have the number that’s stored in LastCU80, dynamically allocated and used as a summation lookback period variable, rather than it being a manual process.

    I can do this by using the line =BarsSince(williams1h Crosses Under 80) in place of the lookback period but it’s way too much load and really not the right way to go about it, as a POC it’s fine and on shorter bar duration it’s okay but on 10k bars 1m for example it’s too much processing all that data.

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

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