Yes, it works - in the sense -> I see 5 plots, but I did not follow the logic of the filter and I can not say (because of lack of knowladge) if this is what You wanted to have.
But, from the syntax, I see that you are trusting to much in the PINE synactic rules and the PINE syntax. What i see here, is that You could include one function inside another
and execute f_savitzky_golay_filter_w_7_vectors inside tripass, duopass and also "vectors" functions.
The thing is, PINE is not perfect (it is being developed for the purpose of just TradingView), and in some cases it can not correcly predict the type of the parameter you read in a function that is executed from inside another function.
This is why You should always reinitiate a pased parameter to some local variable, example:
function doMeFromInside(param1,param2) =>
.....doing sth here ...
function IamAdoerHere(param3,param5)
...some code here...
retFromOther= doMeFromInside(param3,param5)
... some code here...
I had cases where functions like this failed to execure properly (not always this issue persists, I found it's nature is more random which makes it hard to predict) because the passed parameters hadn't had picked up correct type for the variable (float, integer, string): -> in function "IamAdoerHere" let's say I am passing
param3 and param5 as float, but It might happen, they are not correctly initiated by PINE framework in function "doMeFromInside" - they are not being initialized nor any exception is thrown.
What I have found out, is that you need to reinit passed parameters, then IT starts to work again -> reinit ==> in function "doMeFromInside" I do local variable _param1= (param1 + 0.0) and the same, _param5= (param5 + 0.0)
I think that You are doing here code repetitions, because sth was not working without a visible reason. Try always in every function, always reinit all passed parameters with some operation correct for the variable type you expect it to be, then it starts to work.
And another thing is.. that.. the operations order sum "+" "*" and all the other.. are NOT always expanded and agregated in the correct way so it is SAFER to always use paranthesis to group operations.
Another issue is that in functions when you perform operations it is always better to use values in a way speciffic for the variable's type -> numbers to present it in type that you want them to be, example: if You multiply a floating point number by a constant number in a function... then (because of the First thing i wrote here - the issue with variables type selection in PINE"), You better do sth like this: "7.0 * someVariable" instead of this "7 * someVariable".
### The most important thing.. the "precision" keyword, in "study" command - always decide what precision of calculation You want to have, as i found out - PINE has very very limited numbers size when having higher precision set -> this is a bug I have found out lately.. trying for 1 week to understand why some simple equations are not delivering expected values. I had precision set to 6, and was operating on values sth like 10 ^5 -> and i was being returned very very unexpected values - it seems the floting point precision, when set with "precision" keyword is limiting the ordinal max number in the float type variables, because when I had set the preciusion to 4, then miracully, the equations started to expand values that I was expecting to have.
Sorry for the amount of info here, but... from the construction of the script (this one, and previous one) i see, You have encountered, the same issues that I have.
I hope this helps in some way :)
RicardoSantos
⋅
@MasterDisaster, thanks for the feedback, yea the matter of variable type initialization is similar to javascripts, the variable type is determined when its first run, altho i never run into a situation were a float and integer caused conflict as you say. about the rest i agree, pinescript does have so kwerks that need to get used to.
the multipass function in current state is passing the scaling filter function multiple times, theres possibility to reverse the loop wich gives bias strength to last value versus the first in the loop.
But, from the syntax, I see that you are trusting to much in the PINE synactic rules and the PINE syntax. What i see here, is that You could include one function inside another
and execute f_savitzky_golay_filter_w_7_vectors inside tripass, duopass and also "vectors" functions.
The thing is, PINE is not perfect (it is being developed for the purpose of just TradingView), and in some cases it can not correcly predict the type of the parameter you read in a function that is executed from inside another function.
This is why You should always reinitiate a pased parameter to some local variable, example:
function doMeFromInside(param1,param2) =>
.....doing sth here ...
function IamAdoerHere(param3,param5)
...some code here...
retFromOther= doMeFromInside(param3,param5)
... some code here...
I had cases where functions like this failed to execure properly (not always this issue persists, I found it's nature is more random which makes it hard to predict) because the passed parameters hadn't had picked up correct type for the variable (float, integer, string): -> in function "IamAdoerHere" let's say I am passing
param3 and param5 as float, but It might happen, they are not correctly initiated by PINE framework in function "doMeFromInside" - they are not being initialized nor any exception is thrown.
What I have found out, is that you need to reinit passed parameters, then IT starts to work again -> reinit ==> in function "doMeFromInside" I do local variable _param1= (param1 + 0.0) and the same, _param5= (param5 + 0.0)
I think that You are doing here code repetitions, because sth was not working without a visible reason. Try always in every function, always reinit all passed parameters with some operation correct for the variable type you expect it to be, then it starts to work.
And another thing is.. that.. the operations order sum "+" "*" and all the other.. are NOT always expanded and agregated in the correct way so it is SAFER to always use paranthesis to group operations.
Another issue is that in functions when you perform operations it is always better to use values in a way speciffic for the variable's type -> numbers to present it in type that you want them to be, example: if You multiply a floating point number by a constant number in a function... then (because of the First thing i wrote here - the issue with variables type selection in PINE"), You better do sth like this: "7.0 * someVariable" instead of this "7 * someVariable".
### The most important thing.. the "precision" keyword, in "study" command - always decide what precision of calculation You want to have, as i found out - PINE has very very limited numbers size when having higher precision set -> this is a bug I have found out lately.. trying for 1 week to understand why some simple equations are not delivering expected values. I had precision set to 6, and was operating on values sth like 10 ^5 -> and i was being returned very very unexpected values - it seems the floting point precision, when set with "precision" keyword is limiting the ordinal max number in the float type variables, because when I had set the preciusion to 4, then miracully, the equations started to expand values that I was expecting to have.
Sorry for the amount of info here, but... from the construction of the script (this one, and previous one) i see, You have encountered, the same issues that I have.
I hope this helps in some way :)