Good points. From the sounds of it, I agree. Right...nothing new (kNN, etc.). Yes, from what I can understand...our methods share some similarities. How's it working for you in forward testing? Rate of return, etc.? Thanks.
About direction and absolute that you mention in previous post if we are thinking about same thing and you are reffering to outcoms in past then i have tested both methods. About return i made fixed period backtesting screenshots from log of gpb/usd starting 2011 to 13.10. Later period is 2013.10-2016.4. Timing is 1h and bigger spread does not change much as it catches mostly bigger moves and not many trades, after middle red line is data untested, first part from red to red line is testing period. In all this example it made 182 trades ,about 40% winning trades and drawdown is about 33%. Foward testing takes much longer to go trough but seems to give slightly better results than fixed period past and number of trades goes higher if period smaller. But it is altered alot by period, if period too short algo can go wrong directions and if too long then it probably overoptimize to past. For example at the point where backtesting period is over 2008 drop it does not work well for longer term trades after that until period shifted over it. If there are visual similarities before and after testing period like on image it seems to work slightly better than fixed testing period in past and reduce drawdown but i have implemented it lately and not much testing yet.
Nice. What language are you using? Are you using a custom built search algo to optimize parameters? Thanks. For my next version, I have a couple/few more parameters to add. All settings and parameters will have to be optimized via a custom built genetic algo. Even with using JAVA instead of VBA, I expect that I'll be running the algo continuously (for years) as it continually improves itself while searching for the optimal kNN/NN/Etc. parameter settings.
App is c++, for graph opengl, custom search. About direction and absolute did i understand correctly what you ment? I try to reduce settings as much as possible ,depending on different initial settings with my search algo all further settings can go to different directions and it can take very long for all to find same set. One way to help against overoptimization to past may be less settings ,so algo wont be as flexible to fully optimize to past, but it just a thought. Looking at it from other perspectives it maybe good to have more settings and all depends on implementations.
Yes. It sounds like you did. I would use absolute values (more correctly: the change in %), instead of just up/down to test how well a historical day matches recent history. You said you've done it both ways...which do you think works best? Right. But reducing settings may mean making assumptions. The search algo can be coded to start the search using 'assumed' values first, and then mutate them deeper into the search. Right. You never know. That's why proper testing on never-seen forward data is extremely important. Also, having enough samples per inputs/parameters is important. That's why I suspect it will take a very long time to find the optimal configuration...if the optimal configuration can even be found in a reasonable time. It's an art as well as a science.
Could also use both ways at dif steps when interperting data. When get ideas and time i still try different approaches for collecting and interpreting the data, there are many possible ways to test. Your approach to the problem appears same. I made very similar implementation on search algo and later rewrote it more flexible and without depth limit. Of course no point to go more than there are parameters to change. But i have it never gone over 2-3 depth if low timeframe , the possible combinations in 1 depth not extremely big but it grow exponentially. With the way you are thinking it still possible to go trough all combinations ,but work the way differently than regular grid-scanner.