Re: Does this indicator repaint?

272
Cladi39 wrote: Thu Dec 20, 2018 3:13 pm Hello crew, can you confirm if this indi repaint when candle close? Will be be helpfull if you can tell me in what is based. Thanks soo much for your invaluable help.
That is renamed version of Mladen's version of Kase peak oscillator, this is his explanation about it.

These are indicators from Kase StatWare

They have very little in common with the ones posted on the public part of the forum (will post comparison of those too) Wallander will remember the wondering about the 1.92 and 2.08 constants used. Well, these have nothing of a sort.

_____________________________________

First the peak oscillator

Parameters :
kpoDeviations-> deviations to use in calculation
kpoShortCycle-> starting position to calculate values

kpoLongCycle-> ending position to calculate values

kpoSensitivity-> sensitivity modifier used to calculate values

allPeaksMode-> this one needs an explanation
On a lot of pictures showing Kase peak oscillator, every peak is marked regardless of its value compared to deviations. If you turn the allPeaksMode to true, it will work that way, but, frankly, I do not like that mode. See the comparison of the two modes


Also, the way peaks are determined must be explained here. It is marked using the last 3 bars. If the middle one of the 3 is "peaking" than it is marked. It means that if the oscillator is showing the peak in the previous bar, it can be changed (repainted). So the scope of repainting is predictable. If the peak bar is 2nd bar (first closed bar) it can be repainted. Once it becomes the 3rd bar or older there will be no repainting

The question is if it can be usable the way it is calculated. Answer is dual : sometimes it is god damn good even with repainting ad sometimes it is not. Anyway, do not rely on the peaks only, but use the rest of the info the indicator is showing

Difference compared to the "public version" is significant (not just for the "extra lines" but value wise too, see the comparison - upper is this version and lower is the "public version")

Re: Does this indicator repaint?

273
mrtools wrote: Thu Dec 20, 2018 3:45 pm

That is renamed version of Mladen's version of Kase peak oscillator, this is his explanation about it.

These are indicators from Kase StatWare

They have very little in common with the ones posted on the public part of the forum (will post comparison of those too) Wallander will remember the wondering about the 1.92 and 2.08 constants used. Well, these have nothing of a sort.

_____________________________________

First the peak oscillator

Parameters :
kpoDeviations-> deviations to use in calculation
kpoShortCycle-> starting position to calculate values

kpoLongCycle-> ending position to calculate values

kpoSensitivity-> sensitivity modifier used to calculate values

allPeaksMode-> this one needs an explanation
On a lot of pictures showing Kase peak oscillator, every peak is marked regardless of its value compared to deviations. If you turn the allPeaksMode to true, it will work that way, but, frankly, I do not like that mode. See the comparison of the two modes


Also, the way peaks are determined must be explained here. It is marked using the last 3 bars. If the middle one of the 3 is "peaking" than it is marked. It means that if the oscillator is showing the peak in the previous bar, it can be changed (repainted). So the scope of repainting is predictable. If the peak bar is 2nd bar (first closed bar) it can be repainted. Once it becomes the 3rd bar or older there will be no repainting

The question is if it can be usable the way it is calculated. Answer is dual : sometimes it is god damn good even with repainting ad sometimes it is not. Anyway, do not rely on the peaks only, but use the rest of the info the indicator is showing

Difference compared to the "public version" is significant (not just for the "extra lines" but value wise too, see the comparison - upper is this version and lower is the "public version")
Thanks soo much mrtools.


Re: Does this indicator repaint?

280
Cladi39 wrote: Thu Jan 03, 2019 8:30 am


Thanks soo much Mrtools in what is based?
If you have causal = false it will be a recalculating/repainting indicator.
Again from Mladen::

It is a digital filter based on sync() function. In short sync is defined as sync(n) = sin(n*Pi)/(n*Pi) and is, as it is obvious, using a syne wave like shaped coefficients for filtering - smoothing.

But, there is a but : sync can not be used "as is" for that purpose or one will get surprised with the result "jumping around" for different calculating lengths (I know at least one person that did not know that and was even bragging with a "fastest moving average there is" based on sync() and I suppose that by the time he discovered that "jumping effect" al he was left to do is to disappear from internet scene). For purpose of avoiding that, windowing is used. In this indicator I "overdid" a bit and made almost every window variation that is found in wikipedia (here is a link with rather good description of different types of window functions : Window function - Wikipedia, the free encyclopedia ).

After this description, now about some of the parameters. The 3 most important parameters are the frequency cutoff, the filter (window) type and the "causal" parameter.
Filter type can be :

0 - Hamming
1 - Hanning

2 - Blackman

3 - Blackman Harris

4 - Blackman Nutall

5 - Nutall

6 - Bartlet zero end points

7 - Bartlet Hann

8 - Hann

9 - Sine

10 - Lanczos

11 - "flat top"

Frequency cutoff can vary between 0 and 0.5. General rule is that the greater the cutoff is the "faster" the filter is, and the smaller the cutoff is the smoother the filter is.

And the most "problematic" parameter : the causal. In original filters (in digital signal processing) they are mostly using a non-causal (centered) mode since that way they can get a much clearer signal and a delay in a couple of hertzs is not noticeable at all. But in TA it can cause problems. So I decided to have an option to have a causal (non-recalculating, non-centered mode) and a non-causal (recalculating centered mode). One may ask why did I leave the non-causal mode. Well, for estimations, and for some other possible applications, And I like the extrapolation method used in it (it makes the possible error less and less depending on distance from current bar). Recalculation takes is (period-1)/bars (for example for a 15 period filter 7 bars can recalculate : 7th very little, 6th a bit more and so on ... I think that explains the how extrapolation is done) . Here is a comparison of the 2 modes (15 period, 0.01 Bartlet-Hann window types) :



Second indicator attached was a tool I made to check myself if I am doing the windowing OK. Decided to post it here too since it can help greatly in understanding how the filtering is done for some window type and that way it can help. Here is how a Bartlet-Hann window looks like for cutoff 0.1 (left) and 0.01 (right along with filters with same window type and cutoffs
Attachments
These users thanked the author mrtools for the post (total 3):
FBI, rudiarius, Krelian99


Who is online

Users browsing this forum: Banzai, IBM oBot [Bot], rudiarius, SEMrush [Bot], SijjiN, Sogou [Bot], Spazmus, ssscary, Telegram [Bot] and 87 guests