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

inverse · Fri, 17 May 2024 00:32:21 +0000

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

This topic has 21 replies, 3 voices, and was last updated 5 months ago by inverse.

Viewing 7 posts - 16 through 22 (of 22 total)

← 1 2

05/31/2024 at 4:41 AM #233317

inverse

@robertogozzi that bit of code above you posted works with what I was reasoning, sorry for not getting back sooner on it.

Yes the left-most and greater number works well and I can print this too (as well as drawtext it).

When on WR I could also ‘add’ two variables for a total that married with the print to screen, it always looked short by 1 or 2 from memory and I assumed that it was and exclusive count. Given the print to screen marries with the underlying code, it’d make sense perhaps that what I saw was just a knockon of ‘incorrect’ maths. I did think though that when I printed the individual variables and added them it all married.

I just gave it a go and it’s off by two everywhere. You’re LLX=max(LastCO,LastCU) is all good. Thanks for the correction.

Can we use what is contained w/in LLX or the other variables as a lookback for summation?

This would allow for a bit of elasticity or what the old RF guys would call AGC-like action (automatic gain control).

Sorry for being a bit indirect with this I have a family member who has health challenges and my time’s been otherwise spent.

@JS appreciate the horse to water effort and your initial post was on point in allowing me to get to a situation where I might be able go a bit more granular – problem? is the more I do the more I want to do! I’m going through quite a bit of online content atmo (as much as time permits) but time is getting the better of me, no excuses, just life.

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/01/2024 at 10:48 AM #233369

inverse

LLX3Integer = round(LLX3Value) useful in getting some of it done, still a wip….slow going on lower tf., will see how it goes.

1 user thanked author for this post.

robertogozzi

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/05/2024 at 3:07 AM #233502

inverse

Hi Rob,

Could be a bit of a bug or me but when when I apply a WR% as coded by Nicolas in 2016 (way back …. ) (as an indicator) to a 1hr TF there’s nothing displayed on the scale re: current wr levels.

The vanilla WR% as included w/in PRT works on 1hr but the one from 2016 won’t work as expected on 1hr TF.

//PRC_WilliamsRpercent - 01.09.2016 - Nicolas @ www.prorealcode.com


period = 14
hh     = highest[period](close)
ll     = lowest[period](close)
Wp     = ((hh-close)/(hh-ll))*-100
return Wp as "Williams R percent", -20 as "-20 level", -80 as "-80 level"

//PRC_WilliamsRpercent - 01.09.2016 - Nicolas @ www.prorealcode.com

period = 14

hh = highest[period](close)

ll = lowest[period](close)

Wp = ((hh-close)/(hh-ll))*-100

return Wp as "Williams R percent", -20 as "-20 level", -80 as "-80 level"

Appreciate some feedback from you and / or the comm. on whether this a user error or a bug of some kind, perhaps also whether there’s a workaround. Code like – williams crosses under -80 – within a print to screen / draw text has false triggered and it looks to maybe be related to what’s seen above, so when paired with another metric, cci, macd etc, prints/drawings either leverage those states or whatever the WR previous state was.

@JS you did say it was tricky ….

Cheers,

inv

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/05/2024 at 3:36 AM #233503

inverse

Printing to screen will return a ‘zero’, as in ‘0’ at times for williams 1hour metric and can result in an outlier condition (or not even). It’s a level (0) but I’ve not compared it to other TF to see whether there’s anything to it, the other TF are ok and levels seen in scale. This is seen across all indexes I looked at, both in APAC and EU. It could be a transitory state etc which delivers what I’m calling outliers for now which means things aren’t nailed down enough and continues to be a wip for me which is ok but thought wiser minds could look it over and confirm whether it’s a me thing or seen more broadly – this is on PRT Complete supplied by IG.

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/05/2024 at 5:08 AM #233504

inverse

Apologies this is what I have running on a 1hr chart and elsewhere.

period1h = 14
hh1h     = highest[period1h](high)
ll1h     = lowest[period1h](low)
williams1h     = ((hh1h-close)/(hh1h-ll1h))*-100

period1h = 14

hh1h = highest[period1h](high)

ll1h = lowest[period1h](low)

williams1h = ((hh1h-close)/(hh1h-ll1h))*-100

I think the ‘close’ crept in while testing, typical.

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/05/2024 at 8:46 AM #233516

inverse

Apologies for the noise.

WRT the 1hr TF chart not printing WR values on scale during APAC, this looks to be resolved when we head into EU opens.

As far as printing to console goes there’s some lag present on williams1h wr1hr print vs wr1hr print on 1minTF, so while not apples for apples on the lag when printing to screen, it will manifest what I’m calling outliers – it all depends on expectations I guess and I am pleased with outcomes so far (by miles) I can’t get it out of my mind that as the trading day gets busier, fixes applied to scripts during the evening and busy sessions look less than impressive when APAC re-opens. Different market personalities.

I’ve noticed this before and it affects wr but could also hit other indictors as well. I thought at one point it was garbage in script so duplicated and cleaned one up eliminating all but the very necessary (remember I’m learning here, so garbage is a given) and come EU sessions or close to them, perhaps busier APAC, what’s lagged? has come good (again).

I thought I’d settled on a basic screen draw and it was working ‘well’ for a few weeks, possibly month. Since the prior weeks maintenance I felt that APAC just wasn’t right and GUI feedback and erroneous feedback had increased.

TBH it’s probably a me thing in some ways but my 1hr Australia 200 chart would not display WR levels on the scale today and the console prints diverged / lagged at times wildly. As the day progressed this resolved itself and the only change I made was to introduce a script duplicate that was sanitised.

Confused at times but not shattered.

I will say though, makes me think about how an auto-trader would fair through these periods, I’m sure I’ve been here before….the upshot is we’re mickey mouse again with what looks to be a normal working setup.

Really do like that we can o/p to console when investigating.

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

06/09/2024 at 1:57 AM #233648

inverse

Just a bit of feedback on this. Packet loss over here is manifesting in all kinds of weirdness and looks to have resolved 6-7 June.

I’m sure no one notices because on the longer TF it marries well enough optically but because I’m in the process of evaluating the data and how it could be used maybe it’s showing up. Never mind, I thought that as no one else triggered it must have been a me thing. I’m keeping in mind that while evaluating from an auto-trader POV, things are run server-side but I’d like things to marry with what’s printed on scr initially before moving to a demo and using – I think it’s called – ‘graph on price’ to reflect how the system rolls. Not sure what graph on price reveals but hope to get there one day while manual trading alongside an auto-trader, just need to stay vertical.

1 user thanked author for this post.

robertogozzi

inverse

Participant

Topics: 8

Replies: 224

Been thanked: 39 times

Author

Posts

Viewing 7 posts - 16 through 22 (of 22 total)

← 1 2

Find exclusive trading pro-tools on