Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I have VS 2010 and I have converted the project (easy enough by just opening a VS 2008 project from within VS 2010 and it will convert it for you). I know TraderDJB made an attempt at making it work with NT 7 but I haven't had time yet to review to see if I can help. I hope to free up some time in July after the holidays.
- Added "Genetic" optimization in addition to the default brute force optimization
- Added support for optimization on "max. sharpe ratio"
- Added support for optimization on "max. probability"
I didn't see these later posts about the MoGo until now...
The fundamental problem with the MoGo optimizer to getting it from NT 6.5 to NT 7 is that it was built for a very strictly single-core environment and to change it to allow multi-core processing would need... significant re-engineering. (I took a further look at it today.) The new genetic optimizer that NT shipped with NT7 beta 18 is programmed much better and more efficiently than the MoGo and also clearer than PH Genetic though it is almost identical. It really should fill most optimization needs. I've worked to create a variant of NT's GO that is a default optimizer with enum support. Last week, I added the ability to output files that show every iteration run, like MoGo. (I plan to release this mod in a week or so, when I get the time to fix a last bug.)
The only thing left that the MoGo had that these don't is the ability for "parameter constraints" through I never used it long enough to know how that differed from the parameter constraints you normally select when running an optimization. If that was a highly desired trait, I would recommend pulling that specific feature and adding it to NT GO.
What prompted all this optimization programming is that for ALL the genetic optimizers in NT7, 10-15% of the iterations are randomly dropped and so results will be inconsistent even if you run optimizations where every single combination was supposed to be tried - which should produce the same result. I haven't reported this on the NT forum yet, but a workaround for now, is I changed the optimizers to run single core.
Doesn't the genetic search generally have the evolution usually start from a population of randomly generated individuals and happens in generations where the generations themselves introduce a random aspect (i.e., random mutations) from this initial core random starting population? I don't think subsequent GO runs are necessarily supposed to be identical due to these random aspects that genetic search algorithms make use of which are not really supposed to search the whole search space anyways.
@ jdfagan: If the number of combinations possible is larger than the generation size * generations then different results are expected. However, I've tracked results being generated to be tested and then the results not properly captured, even on optimizations of generation size 300, 1 generation and 100 possible combinations so that all were instantly tried. There are duplicate results entry parameters where the parameters going in were not duplicates - in fact, the coding specifically eliminates any redundant trials.
Cool. Thanks for the detailed explanation! So it does sound like the NT GO is still not quite right/efficient if its re-submitting backtests that have been previously run in any prior generation.
One major limitation with NT's implementation was the inability to optimize boolean's and enum's. If they would fix that, it would be a significant improvement.
Thanks for all that you share here on futures.io (formerly BMT)! I do appreciate anything that helps, especially when it has to do with programming which is a real challenge for me.
When I saw this post (and reread it several times) I was in hopes that your 'mod' of the GO was about 'ready to GO [ok .. too punny .. but I couldnt help myself]' . I have been watching this space and have not seen anything new: will you be able to share the update in the nearer future?
