Fast Fourier Transform - Cycle Extraction - page 30

New comment
 

Hi Q,

I haven't gone through the entire code yet but I suspect it is the refresh rate of the indicator that is the culprit. Mladen is better positioned to answer your question and hopefully he can make it "less sluggish" with his new iteration that incorporates some of my ideas in the previous two posts.

Cheers,

Pip

Q_Mouze:
Mr. Pip I tried these indicators in my EA. My PC becomes sluggish. is there a solution?
 

...

Guys

In order to allow any calculation length (lengths other than the 2 powered to n) that indicator (spektrometr) is not using a fast Fourier transform but a "simple" Fourier transform. To remind that "simple" Fourier transform is a O(N[SUP]2[/SUP]) complexity algorithm compared to fast Fourier transform which is a O(N log N) complexity algorithm. The longer the period of calculation is used the slower it will get if the "naive" or "simple" calculation is used (FFT will get slower too but not at that paste).

As far as I see that indicator was not intended to make a long period calculations from the beginning

 

Mladen,

As always, thank you for the insightful feedback. Based on your feedback, would it be of benefit to reprogram the indicator using FFT?

Also, can you define what "long period" would be? The default value currently is 240 bars.

Thanks,

Pip

mladen:
Guys

In order to allow any calculation length (lengths other than the 2 powered to n) that indicator (spektrometr) is not using a fast Fourier transform but a "simple" Fourier transform. To remind that "simple" Fourier transform is a O(N[SUP]2[/SUP]) complexity algorithm compared to fast Fourier transform which is a O(N log N) complexity algorithm. The longer the period of calculation is used the slower it will get if the "naive" or "simple" calculation is used (FFT will get slower too but not at that paste).

As far as I see that indicator was not intended to make a long period calculations from the beginning
 

...

Pip

The "brute force" calculation has an advantage that you can calculate any length but it is even for the default length 240 already a burden (try 1000 and you will see what happens - it will easily go to 30-40% of CPU usage).

The majority of FFT calculations would require that default length (the 240) to be 128 or 256.

There are some fast arbitrary length Fourirer transform calculations but would need to look into them thoroughly and to see if it can be made in mql or it must be made as a dll, but I can not promise when since right now am having some other obligations that are preventing me from seriously looking into this matter, so I will be able to check some more only when those obligations are cleared

Pip:
Mladen,

As always, thank you for the insightful feedback. Based on your feedback, would it be of benefit to reprogram the indicator using FFT?

Also, can you define what "long period" would be? The default value currently is 240 bars.

Thanks,

Pip
 

Mladen,

By all means mate. As always, most appreciative.

Regards,

Pip

mladen:
Pip

The "brute force" calculation has an advantage that you can calculate any length but it is even for the default length 240 already a burden (try 1000 and you will see what happens - it will easily go to 30-40% of CPU usage).

The majority of FFT calculations would require that default length (the 240) to be 128 or 256.

There are some fast arbitrary length Fourirer transform calculations but would need to look into them thoroughly and to see if it can be made in mql or it must be made as a dll, but I can not promise when since right now am having some other obligations that are preventing me from seriously looking into this matter, so I will be able to check some more only when those obligations are cleared
 

Thank you

Thank you Mladen for sharing this FFT! Looks very helpful

 

I had the time to test this out and I have a suggestion. Could it be made in a way so that the iPeriod and iStartFrom would automatically be adjusted. So for example, lets say the user fixes the iStartFrom in a range of 100-20 and iStartFrom in the range of 20-800. Then the Indicator would automatically figure out the best iPeriod and iStartFrom that traced the price price movement after the iStartFrom position the best within those ranges that the user specified. I think this would make this indicator incredible! Any thoughts?

 
saver0:
I had the time to test this out and I have a suggestion. Could it be made in a way so that the iPeriod and iStartFrom would automatically be adjusted. So for example, lets say the user fixes the iStartFrom in a range of 100-20 and iStartFrom in the range of 20-800. Then the Indicator would automatically figure out the best iPeriod and iStartFrom that traced the price price movement after the iStartFrom position the best within those ranges that the user specified. I think this would make this indicator incredible! Any thoughts?

Hi Saver,

What you are looking for is already available in this thread and is called Goertzel Browser

Cheers,

Pip

 

...

Just one quote of what one has to expect when arbitrary length Fourier transform calculations is concerned :

There are also FFT algorithms for data sets of length N not a power of 2. They work by using relations analogous to the Danielson-Lanczos lemma to subdivide the initial problem into successively smaller problems, not by factors of 2, but by whatever small prime factors happen to divide N. The larger that the largest prime factor of N is, the worse this method works. If N is prime, then no subdivision is possible, and the user (whether he knows it or not) is taking a slow Fourier transform, of order N2 instead of order N log2 N. Our advice is to stay clear of such FFT implementations, with perhaps one class of exceptions, the Winograd Fourier transform algorithms.

Re-learning my math

 

...

This is what Winograd Furier Trans_form looks like...one can easily see the divergence over here...still working on Danielson-Lanczos one....

Files:
a.jpg  33 kb
1...232425262728293031323334353637...112
New comment
Reason: