75,000 options - 4GB RAM and 4GB disk cache not enough??? - page 6
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
.... But why is there only 1000 overshoots in such a large space? It's very rough. I ran this Expert Advisor in MT4 over an area of 1.5 billion values and it resulted in 4400 net rebounds within 4 minutes on a history of 18000 EURUSD H1 bars. ....
It depends on the quality of the target function (fitness).
- max NetProfit
- max NetProfit and min DD
- max NetProfit and max PF
- something else?
I did not see such a target function in your code. Here is what we have as optimizing parameters:Besides, we use the original algorithm, which is an order of magnitude faster than other algorithms we know.
I doubt very much about 100-200 runs. What population is used? 16? :) When you start with a large search area you can easily get 256 overshoots in the first generation on 256 population on initial estimate. This is the dirtiest variant. Is this what you mean (run the first population and stop)? Do you believe in results of 100-200 runs on a huge field of variants? Who needs such dirty results?1000 runs is a bit too much, I usually use 100-200 runs (for any number of parameters) to evaluate a solution.
Here's what I got when I ran the MACD Sample in 198 build on your initial conditions from the first page of this thread:
From a search area of 35 billion oversamples, 12800 runs were made in 8 minutes 46 seconds on a history of 18691 bars in "by opening price" mode. The best case report is attached.
In addition, there are a lot of questions about the inconsistent data (all from your reports in the ZIP file). Profits, number of trades, etc. don't even come close to the data in the TSGO report at all (XLS file made for the 880 run, as indicated on the last page of the report).
Also, why is TakeProfit at 80 pips and trailing stop at 6700?
What is the explanation for all this? It seems that your test is so flawed that it cannot be taken into account in any way.
The evidence/explanation should be simple and easy to understand, not confusing to the point where you have to ask questions like this. A screenshot that shows nothing and an archive with inconsistent data is evidence for those who are too lazy to figure it out.
It just might not be clear on the fly ...
Let me explain the results.
1. The optimization criterion may be arbitrary.
(about the target function)
It is calculated by the user himself and passed to TSGO.
I.e. you can use both those ones you have and any other ones a user can dream up.
For example, you can use expected payoffs as a criterion.
(i.e., probability of deals having positive expected payoff, or in other words, the system works on the plus side)
. Or, some criteria describing linearity of equity (it helps to solve problems similar to Walk Forward Optimization) ...
The optimization criterion plays a crucial role in optimization.
(to get the right result, not CurveFitting)
2. Optimization can be done simultaneously according to many criteria.
(about the target function)
I only have a prototype of the next version of TSGO at home.
You can set multiple optimization criteria simultaneously in it (see TS.GO.Criterion(...) function).
In the example in the table of the viewer the criteria used are highlighted with yellow background - they are NetProfit, MaxDD, ProfitFactor.
I.e. TSGO searched for systems around the maximum of these three criteria (MaxDD in Omega is with a minus sign).
I.e. he searched for systems with large profit, with large ProfitFactor and minimal DrawDown.
Interesting results can be obtained simultaneously maximizing NetProfit for each year (or month),
i.e. looking for systems with good results for each year or even month on history.
(in TSGO optimization criteria can be set up to 1000, in reality I have tried so far about 150-200 - this is NetProfit by months on MSFT)
3. Our population size is up to 1000 copies (we could do more, but it seems to be too much).
(I highly doubt 100-200 runs. So what kind of population is used? 16? :))
In that particular example, I think it was 100 (see the parameter value in TS.GO.Popul(...))
I usually use population of 50-100, sometimes 1000.
In general this has little effect, you can always set it to 1000, it has almost no effect on the search speed.
Results are very accurate, even with 500 runs with a population of 1000 ... :))
Also, I wrote that I use my own original algorithm, which so far in the internet have not seen anything about.
It is much faster than all other algorithms I know (and probably used by you).
The size of the population in it doesn't matter (as long as it's not too small) ...
Is this what you mean (to run the first population and stop)?
That's what you say, it works differently for me.
Do you believe in results of 100-200 runs on a huge field of variants?
I do. What's more, I'm pretty sure that the results of CS are independent of the number of variants in the parameter space.
Who needs such dirty results?
They're not messy, they're reasonably sufficient.
You're never guaranteed to get accurate results in CS.
The only way to get an accurate result is to do a complete overshoot.
That is, you always have an estimate - an approximate result.
My algorithm can get a good estimate in most cases as early as 100-200 runs.
Out of a search area of 35 billion searches, 12800 runs have been made
In my algorithm 2000 runs were more than enough.
Unfortunately your reports are not as simple and indicative as in MetaTrader. You posted the XLS report file from Omega with population run number 880, although there are no descriptions of the found parameters of this 880 run anywhere (neither in the XLS report itself, nor in the TSGO report, nor in the screenshots of this thread).
What to do ...
If Omega Research bought our TSGO and built it into their package, then it would be just a checkbox like yours.
But for now it's just an Add-On to TradeStation.
Everything is correct with the results.
Run 880 is the best according to Omega (by NetProfit criterion),
but not the best according to TSGO (simultaneously by NetProfit, MaxDD, ProfitFactor criteria)
TSGO uses Omega only for organization of cycle by passes.
Besides, you can select any criterion available in Omega, and it doesn't affect the work of TSGO.
TSGO does the optimisation based on the criteria specified by the user in the signal code.
The number of the run obtained in Omega does not play any role either.
When the optimization is complete, the results are given for the instance from the first line of the viewer.
In addition, there are a lot of issues with the inconsistent data (all this is from your reports in the ZIP file). Profits, number of trades, etc. don't even come close to the data in the TSGO report at all (XLS file is made for run 880, which is indicated on the last page of the report).
Yes, one can get that feeling, you've done a really great job parsing my example ... :))
A bit of clarification is needed here.
The point is that TSGO uses one feature of Omega to report the best system found.
The best system is the first line from the viewer, substitute its parameters and you will see a full match of the results with the report.
Omega searches for the system according to its criteria (we don't care which one),
TSGO searches for the system according to its criteria, set in the signal by the user.
During the optimization process, Omega changes the Gen parameter from 1 to K (this is the optimization parameter set in Omega).
The value of Gen is sent to TSGO.
If Gen increases, then TSGO outputs parameters of the new candidate to test the results of the run.
If Gen didn't increase, then TSGO considers the optimization is over (Omega recalculates the best result in its opinion),
in this case TSGO outputs the parameters of the best found instance (from the first line of the viewer).
In general, when the optimization is complete, the Omega report shows the results of the instance from the first line of the viewer.
Compare their parameters and they are exactly the same.
All this is because TSGO is an Add-On to Omega and not a part of it.
There's no other way to do it.
============================================================================
Renat, I assure you that this is absolutely real data, and everything in it is absolutely correct.
The confusion arises because we are not the developers of Omega and we can't build the optimizer inside Omega.
Do you believe in the results of 100-200 runs on a huge field of variants?
Don't be a believer. Would you be so kind as to prove your point on this recount:I do. Moreover, I'm pretty sure that the results of CS don't depend on the number of variants in the parameter space.
The results are correct.
So:Run 880 is the best according to Omega (according to NetProfit criterion),
but not the best according to TSGO (by NetProfit, MaxDD, ProfitFactor criteria simultaneously)
- You haven't listed the best run parameters found 880
- You tell us that "black is white", justifying it with the peculiarities of your addon
- You sent a knowingly incorrect Omega report
- You have not indicated exactly what target function you used to get the results of 1000 runs, and instead went into the "you can do this or that" mode (the programmer can set the criterion in the code himself - show this criterion in your EL code)
Don't _confirm_ me. Better _prove_ on numbers and reports. You have forced us to move to the field of solving problems at the level of "horses in a spherical vacuum" (thank you for that), we have moved and solved the problem. But you have not solved it in any way, and you have even misled us with wrong reports.Everything you have cited earlier as evidence since the start of this thread is utter nonsense with word games. There is no proof, just a game of outlandish numbers. Would you be so kind as to take IBM Daily from 1970 to 1999 (exactly from early 1970 to early 1999) and run the above (exactly their) limits and publish such a report so that there is no claim to it. And I'll publish mine.
And why do I always have to make excuses here?
If you want me to leave the forum, please.
Just ban me here too, and I'll do more work and less distractions.
If you don't understand something, it doesn't mean you've been lied to.
It just means you don't understand, and in polite society.
people just ask for explanations for things they don't understand.
People usually judge others by themselves.
I for one have never once questioned the honesty of forum participants.
(Unlike you...).
I'll answer in order.
1. In one of my posts I wrote:
In addition we use the original algorithm, which is an order of magnitude faster than other algorithms we know.
1000 runs is a bit too much, for estimating a solution I usually use 100-200 runs (for any number of parameters).
You have answered me:
Do you yourself believe in the results of 100-200 runs on a huge field of variants?
Don't have faith. Would you be so kind as to prove your words on this recalculation:I do. Moreover, I am absolutely sure that the results of CS do not depend on the number of variants in the parameter space.
---
What do I have to prove to you?
That "I usually use 100-200 runs (for any number of parameters)" ?
And I consider such results to be sufficiently reliable?
That is my opinion, and why should I prove it?
You do not think so? - That is your right.
You can just say, "I don't think so."
There will be two opinions on the same subject.
2. You have not given a list of the best parameters found for the 880 run
The 880 run is not the best in terms of TSGO,
and it may no longer be in the population.
The best run is 919, which is shown in the first line of the TSGO viewer.
It is the one you see in the Omega report.
Compare.
In the viewer, line 1.
Gen = 919 (this is the number of the run)
Trades = 52
NetProfit = 29312.07
MaxDD = -4939.19
PF = 7.42
In Omega's report
Total Net Profit = $29,312.07
Total # of trades = 52
Max intraday drawdown = ($4,939.19)
Profit Factor = 7.42
Why Omega made the run number 880, I've written in a previous message.
3. You have sent me a false report from Omega.
I sent a deliberately false report Omega, look more carefully.
4. You did not specify exactly which target function you used to get the results for 1000 runs
I already wrote it in my previous post, the optimization was performed simultaneously using three criteria - NetProfit, MaxDD, ProfitFactor. They are highlighted in the viewer with yellow background.
In the signal code in Easy they are defined by TS.GO.Criterion function
Here is a code snippet:
R = TS.GO.Method(1); -- enabling multi-criteria optimization.
R = TS.GO.Criterion("NetProfit",1); -- first criterion
R = TS.GO.Criterion("MaxDD",1); -- second criterion
R = TS.GO.Criterion("PF",1); -- third criterion
Criteria values are assigned at the end of the code on the last bar:
R = TS.GO.Set("NetProfit",NetProfit);
R = TS.GO.Set("MaxDD",MaxIDDrawDown);
R = TS.GO.Set("PF",GrossProfit/(0.001-GrossLoss));
I have no desire to listen to your attacks.
If we're going to talk, we need to be on an equal footing.
Do you agree?
Then please try to prove your assertions.
1. You sent an obviously false report to Omega.
2. You have not indicated exactly which target function you used to get your results.
3. And you haven't solved it yourself in any way, and you've also misled it with incorrect reports.
4. Everything you have given earlier as evidence from the beginning of this thread is complete nonsense with word play. (This is not just an assertion - it is already an insult)
5. There is no evidence, just a game of outlandish numbers.
I keep suggesting to move from the realm of word games solely into the realm of practical reports. Last time I suggested the problem to be solved again. Can you solve it and publish reports that are unquestionable?
After this task, we can move smoothly to a statement about the sufficiency of 100-200 runs on huge fields of variants.
There was only one misunderstanding with the Omega run number.
In the next post I explained to you in detail what this is about.
About the sufficiency of 100-200 runs on huge variant fields.
I did not make a statement or assertion.
I literally wrote the following:
... I usually use 100-200 runs (for any number of parameters) to estimate a solution
Do you understand the difference between "estimation" and "sufficiency"?
This is especially interesting when it comes to reports and proofs, as I usually ask for - plain and simple. You need computer reports that come with a maximum of one line of author's commentary each.
I'd be happy to explain in two words, but if you don't understand that, I have to write kilometre-long posts ...
After this assignment...
And you hired me to give me assignments?
I keep waiting for you to prove your CONCLUSIONS.
If you are making outrageous technical claims, be kind enough to prove them.
We have already dealt with 100-200 runs and it turned out to be absolutely dirty (albeit "estimated") results (I said that right away, but you didn't agree). And you had to admit it only under pressure.
I don't make outlandish technical claims.
To be more precise - for you they may be out of bounds, but for me they are quite ordinary, working ones.
We have already dealt with 100-200 runs and it turns out that these are absolutely dirty (albeit "estimated") results (I said it right away, but you didn't agree). And this you only had to admit under pressure.
They are not "absolutely dirty" but quite workable results.
And I didn't agree to anything under any pressure.
I've said the same thing all along, I can say it again.
Especially for you,
I ran another optimization in Omega.
I left only one optimization criterion - NetProfit- to make it easier for you.
The same criterion was used in Omega.
There were 1000 runs in total.
IBM, 7800 bars, to 1999/12/31
(Omega has no start date of period, has end date and number of bars)
Testing on daily bars by Close bar (by Open Omega does not do)
Stops, toes and trailing in code made by pending orders,
as Omega inside bar does not work otherwise and data only have daily bars.
In the attachment:
@Renat.txt - EL signal code, differs from the previous one in that only one criterion is left.
1000.XLS - Omega system report (best run according to Omega)
SOR.xls - Omega test report (all runs)
TSGO-1000.CSV - composition of last population in TSGO (population size 100).
The block of criteria definition has been changed in the signal code:
R = TS.GO.Method(1);
R = TS.GO.Criterion("NetProfit",1); -- second parameter = 1 - looking for maximum criterion
R = TS.GO.Criterion("MaxDD",0); -- second parameter = 0 - optimization by criterion is disabled
R = TS.GO.Criterion("NetProfit",1).GO.Criterion("PF",0); -- second parameter = 0 - optimization by criterion is disabled
Please note
1. The first line in the viewer corresponds to the first line in the population and corresponds to the results in Omega.
2. the number of the best run in the viewer is 401, in Omega 948, if you look in SOR.xls you will see that these runs have the same results. TSGO rejects repeated matching results.
3. If you look at the composition of the last population, you will see that the best found result has NetProfit 1891.86 (on 401 runs), the result of 213 runs is 1814.16, the result of 93 runs is 1796.40. I.e., the result for the 93rd run was different from the best result after 1000 runs by 5.3%, which I think is not bad and can be considered as a good NetProfit estimation.
Below is a screenshot