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

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

1 2 →

Author

Posts
05/17/2024 at 1:32 AM #232746 quote
inverse
Participant

New
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 …. 🙂
```
OB = summation[LookBack4](Williams4h crosses over -20)

OS = summation[LookBack4](williams4h crosses over -80)
```
```
IF OS then
drawtext("OS",xstart-70,ystart-200,dialog,bold,14) coloured("Blue") anchor(topright,xshift,yshift)


elsif OB then
DRAWTEXT("OB",xstart-70,ystart-200,SansSerif,Bold,14)coloured("darkred")anchor(topright,xshift,yshift)
```
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:
```
= summation[LookBack4](Williams4h crosses over -20 or Williams4h > -20)
```
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.
```
else


DRAWTEXT("WIP...",xstart-80,ystart-200,SansSerif,Bold,14)coloured(64,64,0)anchor(topright,xshift,yshift)
```
Many thanks,

inv

robertogozzi thanked this post
05/17/2024 at 11:14 AM #232756 quote
robertogozzi
Moderator

Master
This code seems to work as you expect:
```
Timeframe(default)
once LookBack4 = 10
xstart         = -50
ystart         = -20
//
Timeframe(4h,updateonclose)
Williams4h = Williams[14](close)
OB = summation[LookBack4](Williams4h crosses over -20)
OS = summation[LookBack4](williams4h crosses under -80)
//
Timeframe(default)
IF OS > 0 then
   drawtext("OS",xstart,ystart,dialog,bold,14) coloured("Blue") anchor(topright)
elsif OB > 0 then
   DRAWTEXT("OB",xstart,ystart,SansSerif,Bold,14)coloured("darkred") anchor(topright)
endif
return
```
I just replaced OVER by UNDER in line 9, if that’s not what you want you may restore OVER.

inverse thanked this post

x-3.jpg
05/17/2024 at 8:55 PM #232777 quote

inverse
Participant

New

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.

05/20/2024 at 10:14 PM #232840 quote

inverse
Participant

New

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 .. 🙂

robertogozzi thanked this post

05/27/2024 at 11:56 AM #233084 quote
inverse
Participant

New
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.
```
a = (williams4h crosses under -80)

testa = barssince (a,1)

testb = barssince (a)




a1 = (williams4h crosses over -20)

testa1 = barssince (a1,1)

testb1b = barssince (a1)
```
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.
05/27/2024 at 1:16 PM #233090 quote
inverse
Participant

New
Had another look and came up with the following, not sure tbh.
```
if testb > testb1 then // the last OB further away than the last OS = OS most recent

DRAWTEXT("OS",xstart-80,ystart-240,SansSerif,Bold,14)coloured("blue")anchor(topright,xshift,yshift)

elsif testb1 > testb then // the last OS further away than the last OB = OB most recent

DRAWTEXT("OB",xstart-80,ystart-240,SansSerif,Bold,14)coloured("darkred")anchor(topright,xshift,yshift)

endif
```
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.
05/27/2024 at 2:02 PM #233094 quote
JS
Participant

Veteran
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)
```
DefParam DrawOnLastBarOnly=True

FastMA=Average[10,0](Close)
SlowMA=Average[20,0](Close)

If FastMA Crosses Over SlowMA then
COBarIndex=BarIndex //Value of the crossover BarIndex
COValue=High //Value of the crossover Price
EndIf

If FastMA Crosses Under SlowMA then
CUBarIndex=BarIndex //Value of the crossunder BarIndex
CUValue=Low //Value of the crossover Price
EndIf

DrawArrowUp(COBarIndex,COValue)Coloured("Green")
DrawArrowDown(CUBarIndex,CUValue)Coloured("Red")

LastCO=BarsSince(FastMA Crosses Over SlowMA)
DrawText("Bars Since Last CrossOver=#LASTCO#",0,50,SanSSerif,Bold,24)Anchor(Bottom) Coloured("Green")
LastCU=BarsSince(FastMA Crosses Under SlowMA)
DrawText("Bars Since Last CrossUnder=#LASTCU#",0,100,SansSerif,Bold,24)Anchor(Bottom) Coloured("Red")

Return FastMA as "FastMA" Coloured("Red"), SlowMA as "SlowMA" Coloured("Blue")
```
inverse thanked this post

Schermafbeelding-2024-05-27-om-15.02.35.png
05/27/2024 at 9:35 PM #233115 quote

inverse
Participant

New

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.
JS thanked this post

05/27/2024 at 11:25 PM #233117 quote

JS
Participant

Veteran

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

inverse and GraHal thanked this post

05/29/2024 at 11:33 AM #233216 quote
inverse
Participant

New
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?)!
```
LastCO=BarsSince(williams1h Crosses Over -20)

LastCU=BarsSince(williams1h Crosses Under -80)

LLX=LastCO+LastCU

DrawText("Total LB=#LLX#",xstart-80,ystart-10,SansSerif,Bold,14)coloured("darkred")anchor(topright,xshift,yshift)
```
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.
05/30/2024 at 6:43 AM #233260 quote
JS
Participant

Veteran
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… 😉

inverse thanked this post
05/30/2024 at 11:34 AM #233279 quote
robertogozzi
Moderator

Master
@inverse line 5 of your last code reads:
```
LLX=LastCO+LastCU
```
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:
```
P     = 10
Sma10 = average[10,0](close)
Co    = BarsSince(close crosses over  Sma10)
Cu    = BarsSince(close crosses under Sma10)
DrawText("#Co#",BarIndex,high + highest[p](range))
DrawText("#Cu#",BarIndex,low  - highest[p](range))
return
```
as adding the two values would return an incorrect value, just take note of the leftmost one of the two (the greatest value):
```
LLX=max(LastCO,LastCU)
```
and if you need to know how many bars have elapsed in between the two, subtract them (using ABS to always get positive results):
```
DIFF=abs(LastCO - LastCU)
```
inverse thanked this post

x-5.jpg
05/30/2024 at 12:41 PM #233289 quote
inverse
Participant

New
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).
```
LastCU80=BarsSince(williams1h Crosses Under -80)
DrawText("Bars Since XU-80=#LASTCU80#",0,-80,SansSerif,Bold,14)Anchor(top) Coloured("Blue")
```
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.
05/30/2024 at 1:06 PM #233291 quote

inverse
Participant

New

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.
JS thanked this post

05/30/2024 at 10:34 PM #233315 quote

inverse
Participant

New

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.
Author

Posts