Trading Strategies Based On Digital Filters - page 33

New comment
 
SIMBA:
Care to share your results?..And the right way to set the data ,comma,etc issue...it will be a thrill for us to be able to do and share too

sure thing...

I simply copied my date comma settings exactly like ND did....

I then loaded robertinno's data....and this is what i got ( see attachment)...

I'm guessing he used different data....and posted an example of "how to" do the roc in excel....my spectrum looks nothing like his....no matter how many records you put in there....

cl

Files:
change_in_n_2.gif  129 kb
 

ND,

THAT WORKED!!!! Thanks bro!!!

Do what Newdigital says and try again. By looking your picture you have a big problem with your imported data.

See by yourself, there is a completely inconsistence with your candles.

Yo Linuxser,

Thank you for your advice. The reason the candles look that way is not because something is wrong w/ the imported data but instead because they are actually not OHLC candles. It is ROC data (If I'm not mistaken). Different method of SA brought to us by robertinno that supposedly gives a more accurate output because it's based off non-stationary time series that is the financial markets vs. usual unrealistic stationary analysis (Someone correct me if I'm wrong). THAT'S from where the issue arose. It was a different type of data and from a computer (robertinno's) w/ different date format, thus those w/ a different default date format was encountering problems uploading and we were thinking it was the fact that is was a different type of data. Whew!

I digress........

We have overcome that thanks to everybody's brainstorming and teamwork.

well put... :-)

 
newdigital:
I just explained my experience.

When we are using some tool to import the data to non-Metatrader software (to asctrend software by ForexClub tool for free instead of using esignal; and so on) so we may have this problem: Windows settings of the date and numbers. And it depends on where this software was created, and it depends on which Windows you have.

For example, my Windows is in Russian language. It means that 1,000 is one in this Windows (and in Russian language). And 1,000 is one thousand if you are having English language Windows. And the same cases with deviders. And it is different for Europe and Asia as well.

So, if you are converting the forex data from one software to the other one using some of free tool (there are a lot of free tools) so this tool will do it according to your Windows settings in most of the time.

Just go to Control Panel, Languages and Standards and change the format and you will understand.

The most important thing is devider: it can be comma or semicolon.

For example:

1.9864,25.01.2006 (if comma)

or

1.9864;25.01.2006 (if semicolon).

When the data is imported so your Windows can understand the comma as a devider between some data and you can get an error.

So, check it in your Windows settings and change if necessary (but it is not related to american Windows as it was setted in right way already). But as I know the creator of this DFG is Russian so, may be, he programmed comma instead of semicolon and because of that I do not have any error (i did not get error and my devider in Windows settings is comma by default).

ND,

THAT WORKED!!!! Thanks bro!!!

Linuxser:
Do what Newdigital says and try again. By looking your picture you have a big problem with your imported data.

See by yourself, there is a completely inconsistence with your candles.

Yo Linuxser,

Thank you for your advice. The reason the candles look that way is not because something is wrong w/ the imported data but instead because they are actually not OHLC candles. It is ROC data (If I'm not mistaken). Different method of SA brought to us by robertinno that supposedly gives a more accurate output because it's based off non-stationary time series that is the financial markets vs. usual unrealistic stationary analysis (Someone correct me if I'm wrong). THAT'S from where the issue arose. It was a different type of data and from a computer (robertinno's) w/ different date format, thus those w/ a different default date format was encountering problems uploading and we were thinking it was the fact that is was a different type of data. Whew!

I digress........

We have overcome that thanks to everybody's brainstorming and teamwork.

 

Curve fitting vs. Retuning?

Hi All,

Fascinating thread. Thanks to all who keep it moving. I have a question for you gurus if you don't mind.

Question: What about curve-fitting and the need for re-tuning? It seems clear to me that this type of analysis is extremely curve fit - intentionally, as part and parcel of the method. It reminds me of some of what I have read about the AI techniques - neural nets, etc. I have also read that daytraders successfully using neural techniques have to regularly re-optimize or re-tune their indicators for the indics to continue to have precision and relevance to the current market - some as often as every day.

What about these DF methods? Is re-tuning (or, re-optimization) necessary? How often? Also, what about the difference between using the shorter "learning period," like 200-300 bars, vs. all available bars? If FATL, SATL, etc are created using 200-300 bars, how often would you advise re-tuning the filters to continue to generate curve which are truly descriptive and not starting to fall apart?

I will begin experimenting with some of these methods soon myself, once I get up to speed on the concepts. I imagine doing a manual backtest of some basic ideas. However, I don't think it would be genuine to backtest against indicators which have been highly optimized to the (known) back data and then expect the (unknown) future to hold to that optimized result. I am thinking it might be best to tune the filters to a 200-300 bar window, then forward test against the next, say 100 bars, then step the 200-300 bar tuning window forward 100 bars, then test against the next 100 bars, etc, etc, to create a full backtest against fairly realistic conditions.

Any advice or comments?

Best,

Scott

 
turboscottomatic:
Hi All,

Fascinating thread. Thanks to all who keep it moving. I have a question for you gurus if you don't mind.

Question: What about curve-fitting and the need for re-tuning? It seems clear to me that this type of analysis is extremely curve fit - intentionally, as part and parcel of the method. It reminds me of some of what I have read about the AI techniques - neural nets, etc. I have also read that daytraders successfully using neural techniques have to regularly re-optimize or re-tune their indicators for the indics to continue to have precision and relevance to the current market - some as often as every day.

What about these DF methods? Is re-tuning (or, re-optimization) necessary? How often? Also, what about the difference between using the shorter "learning period," like 200-300 bars, vs. all available bars? If FATL, SATL, etc are created using 200-300 bars, how often would you advise re-tuning the filters to continue to generate curve which are truly descriptive and not starting to fall apart?

I will begin experimenting with some of these methods soon myself, once I get up to speed on the concepts. I imagine doing a manual backtest of some basic ideas. However, I don't think it would be genuine to backtest against indicators which have been highly optimized to the (known) back data and then expect the (unknown) future to hold to that optimized result. I am thinking it might be best to tune the filters to a 200-300 bar window, then forward test against the next, say 100 bars, then step the 200-300 bar tuning window forward 100 bars, then test against the next 100 bars, etc, etc, to create a full backtest against fairly realistic conditions.

Any advice or comments?

Best,

Scott

Scott,

I only have a quick minute, but i wanted to give you my comment. In terms of "re-tuning", we haven't really gotten into that much but that's not to say it hasn't come up. My .02 would be ( and this has been SIMBA's advice in the past) is that when using SATL, FATL ( which leads to STLM and FTLM), we try to use the least amount of bars possible. I would think then that maybe every week, you could reoptimize with the past 200 bars or so. Reoptimize on Saturday for example, and use the coefficients for the upcoming week. The "cycles" we've been creating we haven't really touched on that. Since we are using full history, i would assume you wouldn't have to reoptimize as often. That's not to say you wouldn't have to ever though.

Sorry but i have to run. I'm sure someone else will comment further on this.

Thanks,

cl

 

thanks

Thanks cl - I appreciate the input. From what I am reading here on the board, as well as the original papers (on Robert's site), it looks like anyone using these techniques is working on the frontier and will need to do a lot of experimenting and discovery by trial and error. MUCH more interesting than working with methods with well-known (and well-worn) histories, like most of the classic TA indicators. I can't wait to get into this a little myself. Unfortunately, I am moving over the next 3 weeks and that will take priority, but that's my cross to bear.....

best,

Scott

 
barnix:
Singular Spectrum Analysis: SSA

Библиотека функций сингулярного преобразования - MQL4 Code Base

Time series analysis and forecast, Caterpillar SSA method [Software]

Yo Barnix,

This is some deep stuff. You must be trying to give me a headache before I go rollerskating. lol! Thanks for sharing, bro. Don't be a stranger as I might be asking just a couple of questions

From what I've understood thus far, this method works very well w/ non-stationary data.

FEI (For Everyone's Information)

You must place the SSA file in the include and/or library folder and the #_FullSSA_normalize in the indicator's folder.

 
barnix:
Singular Spectrum Analysis: SSA

Библиотека функций сингулярного преобразования - MQL4 Code Base

Time series analysis and forecast, Caterpillar SSA method [Software]

I've been messing around with this indicator tonight, running it through VHands. It's a hog on memory for sure. My question comes about from the calculation. The line continually repaints and recalculates itself, so in the past it looks great. The "Lag" extern controls this. "10" seems to make the past 10 bars or so recalculate. A number of "3" is much more jagged, and it doestn' repaint as much of the past as the 10 does. I'm not too for sure what "real time" applications this indicator would have. It reminds me a lot of fisher indicators. Perhaps there is a coding error that makes it repaint? I'm guessing not, but i thought i would just post what i noticed...

Best,

cl

 

On the SSA:

I, as well as several other members, have experienced "recalculating" of this indicator. Can change after several closed bars. Not sure if this a bug or if this indicator is meant to be like Zigzag i.e. dynamic. Whatever the case, anyone using it, I encourage you to exercise caution when doing so.

Perhaps Barnix would be so kind as to shed some light on this topic. Could be that I am not using it in the manner intended. If this is so, I apologize for jumping to conclusion. Barnix is one of the few highly skilled members, of whom's work I am familiar so I seriously doubt he'd intentionally give us a faulty product. I hope he is still lingering and see's this message. I am eagerly awaiting further discussion on the topic.

On DF's:

For those interested, there is an indicator that was coded by the creator of the DFG software, Sergey Iljukhin. It includes .DLL's that call functions from the DFG software, allowing the creation of Low-Pass filters directly in MT4. The purpose of using DFG then becomes solely for spectral analysis. Much easier to fine-tune and test against live data vs. traditional method of using DFG for whole process. Visit this link to download the indicator and .DLL's files.

Very good indicator IMHO. I am curious to know if any of the programmers would be interested in undertaking a project to create a similar indicator that allows for the creation of optimized FTLM and STLM filters. This would further the progress of more user friendly methods to optimize and create digital filters fitted to diff. timeseries.

Also, some possible mods the current DigitalFilter.mq4 indicator to include a couple extra things such as Price Customs and a description of the types of filters that can be created and the numerical value to which they correspond in the parameters vs. having to open indy in MetaEditor to find out or trying to memorize it amongst other changes that I believe (based of research between Simba, CLahn, and myself) would yield a robust set of indicators.

W/ these, we're one step closer to auto-optimized DF's directly in MT4. Jojo recently created a spectral analysis indicator for MT4 using Goertzel algorithm. Unfortunately, Jojo hasn't been posted on the thread since so we are at a loss on how to correctly apply it to our cause. As it stands now, we are @ a point of stagnation. If and when we know how to marry the MT4 DF indicators w/ the Goertzel SA indicator.... .

Looking forward to any and all feedback.

1...262728293031323334353637383940...138
New comment
Reason: