Hello Nicolas,
You’re welcome.
your list of conversions in progress is not up to date : some indicators have been already converted (trendilo, ut bot alerts…) and others can’t be converted because the code is not available (smart money concept for example) because the script is published closed-source.
I have also my own list of conversion to do… 🙂
But i can try to convert 1-2-3 pattern.
For smart money concept, there is those 3 scripts that can be equal if not better than the one of the conversions list :
https://www.tradingview.com/script/CnB3fSph-Smart-Money-Concepts-LuxAlgo/
https://www.tradingview.com/script/ib4uqBJx-ICT-Concepts-LuxAlgo/
https://www.tradingview.com/script/ZpHqSrBK-Market-Structure-CHoCH-BOS-Fractal-LuxAlgo/
I still can’t add post in the Library…
When i try, i am asked to upload a picture, and i can fill everything but i can’t upload the ITF file, and my post does not appear in the Library…
When i click on “Add/Edit Attachments” nothing happen, i just return at the top of the same page.
How can i do to solve that bug?
Thanks
Thanks for the upload! I appreciated it a lot.
Post have to be reviewed in order to be public. Will review it asap 🙂
ITF file upload is not necessary, I will make it myself if you have added the code into your content.
Ok,
Itf file have been uploaded 2 posts above
WimParticipant
Junior
With respect to the Hypertrend (from LuxAlgo) conversion to PRT. I am not convinced that this conversion reliably copies the Tradingview behaviour. I compared the Tradingview chart with the PRT chart for the S&P500 in the first quarter of this year. Screen captures added. Of course with exactly the same configuration, 5, 14 and 80 (defaults).
The number of channel changes is modest in Tradingview, and huge in PRT. I guess that some Tradingview-math has been ill translated. Seems worthwhile to have someone check it and propose a correction?
Maybe AverageTrueRange is not calculated the same way on TradingView and ProrealTime ?
On Prorealtime, Average True Range is calculated by applying a Wilder moving average to the True Range
while on TradingView a Relative Moving Average is applyed to the true range…
Relative moving average does not existe on prorealtime ?
Is it possible to compage atr on both ?
This is the standard formula for the ATR indicator:
// ATR formula
//
// https://en.wikipedia.org/wiki/Average_true_range
// https://www.youtube.com/watch?v=jjsje1E3hVM
// https://www.investopedia.com/terms/a/atr.asp
// https://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:average_true_range_atr
//
// Calculation of TR:
//
// The range of a day's trading is simply high − low {\displaystyle {\text{high}}-{\text{low}}} {\displaystyle {\text{high}}-{\text{low}}}.
// The true range extends it to yesterday's closing price if it was outside of today's range:
//
// MyTR = max(Range,max(abs(high − close[1]),abs(low − close[1])))
//
// The true range is the largest of the:
// Most recent period's high minus the most recent period's low
// Absolute value of the most recent period's high minus the previous close
// Absolute value of the most recent period's low minus the previous close
//
// Calculation of ATR (of P periods):
p = 10
MyTR = max(Range,max(abs(high - close[1]),abs(low - close[1])))
IF BarIndex < p THEN
MyATR = MyTR
ELSE
MyATR = ((MyATR[1] * (p - 1)) + MyTR) / p
ENDIF
RETURN MyATR
Strange how i get 3 differents results for ATR[200]
First is ATR from prorealtime, second is calculated with the RMA script found below, and last with the script of ATR formula above…
RMA – Recursive Moving Average
Not sure which one stick the more to the ATR calculated by tradingview.
Also an other explanation could be the operators’ precedence that can be different on prorealtime and tradingview…
If someone else can help, it would be appreciate 🙂
WimParticipant
Junior
The difference in ATR between Tradingview and PRT doesn’t explain the large number of channel changes in PRT. I do acknowledge that the Tradingview ATR values are roughly 8 points higher than those calculated by PRT. Adding this offset to PRT doesn’t change the number of channel changes. Something else going on there too.
Back to the ATR calculation. As shown in the screen captures the ATR of Tradingview lies roughly between 20 and 25, whereas the ATR of PRT lies between 10 and 15 for the first quarter of 2023. The PRT screen capture shows the standard ATR and Roberto’s ATR. They are identical.
We need a Tradingview-PRT-detective to research on the correct conversion of the mathematics I guess.
The difference in ATR between Tradingview and PRT doesn’t explain the large number of channel changes in PRT. I do acknowledge that the Tradingview ATR values are roughly 8 points higher than those calculated by PRT. Adding this offset to PRT doesn’t change the number of channel changes. Something else going on there too.
It does, because of line 15 in the script
“If abs(close – avg) > atr then“
More ATR is bigger, less channel change there will be.
If ATR is 8 to 10 points less in Prorealtime, then there will be more change in channel.
Also 8 to 10 points more than 10 to 15 points is 80% more… It is a huge difference!
I found the formula of RMA of tradingviw, hr blow, i will do the conversion to have the same atr, but i have no time today (traveling day)
https://fr.tradingview.com/pine-script-reference/v5/#fun_ta.rma
https://www.tradingcode.net/tradingview/relative-moving-average/
WimParticipant
Junior
I found the reason behind the big difference in charts Tradingview and PRT. The broker chosen by LuxAlgo only gives candles during normal pre-market and market opening hours. PRT/IG gives 24 hourly candles per day. If I switch to another cfd broker dealing all day like IG, you get the same chart as in PRT (including same values for ATR). See screen capture.
What this means with respect to signals given by this indicator with a opening hours only broker versus a 24-24 broker, I do not know. More, less, more or less reliable, … happy backtesting.
No need to change the code, sorry for the fuzz, although I did learn something about the effect of the different brokers on signals given by an indicator.
ZigoParticipant
Master