75,000 options - 4GB RAM and 4GB disk cache not enough??? - page 3
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
An updated build 197 has been posted: it still "trimmed" the actual memory allocation in heavy cases. But there's no way to pull out 57 billion.
sane, download the updated 197 build and try again, please.
In my genetic optimizer you can set up to 1000 parameters, discrete or real,
and population size up to 1000 (could easily make more, but it's already a lot ...).
Everything works and doesn't require any memory (well, except max 1000 x 1000 x 8 = 8 Mb for population storage).
Maximum possible parameter space (number of runs) = (2^(8*8))^1000
I can't get this figure into my head,
It's something like (2^64)^1000 ~ (2*10^19)^1000 ~ (10^100)*(10^19000) = 10^19100
(one with 20 thousand zeros ...)
And it works, even on a Pn3 with 256MB of brains.
Why I've got it working and you can't?
You just did something wrong...
Think about it, correct it.
It's possible.
I think it's just a programmer's slip,
left over from when you didn't have CS yet...
An updated build 197 has been posted: it has also "trimmed" the actual memory allocation in severe cases. But there's no way to pull out 57 billion.
sane, download the updated 197 build and try again, please.
So:
let's test 21600 variants with these parameters:
1. On a laptop with 256mb and PIVM-1.7 terminal crashes maybe even faster than before.
2. On a Celeron with 2GB - it works for now.
on 2/3 of 21600 options about 1.5 gigs of memory i.e. subjectively 3-4 times less, but maybe because there were about 15 prog running during the day and only 4-5 now. the cache has not really crawled yet.
3. maybe the tester should be made a separate process? why should the terminal crash every time? if it crashed, why lose results. make it once in 10% to write as it does when you press stop. by the way, now I think it already does not write when you press stop. )
4. write down the estimated number of runs in the form ^^^ - there's nothing to do there at all - multiply all active lines and write. i bet there is even a variable. just print it out.
5. 1 hour for 21600 options - isn't it slow? Or is it all because of memory again.
6. The logic of the buttons recalculate-optimize-visualize does not logically make sense to me.) as far as I understand either recalculate or recalculate + optimize or visualize, and for the latter you have to select an option in the output.
7. I hope you have the same results so far when working with memory?
[skipped] With your specified limits there would be 57,629,880,000 (57 billion) runs [skipped].
what about me? i have 75000 or so.
and in my opinion the number of runs can be limited to 2yards of course (better to write total below in optimization parameter entry form, in order to avoid counting on calculator or running tester to see how many you get), ...
then the solution can be found in a few hundred (sometimes thousands) runs for any size of parameter space.
So there is no need to calculate anything, 2 yards has nothing to do with it ...
sorry, what is a CS? warranty, civil liability or is there a japanese toy built into the terminal? )
then the solution can be found in a few hundred (sometimes thousands) runs for any size of parameter space.
So there is no need to calculate anything here, 2 yards has nothing to do with it ...
sane, we will post a revised build today. Try again. We changed the memory allocation algorithm.
It's gone. I spent an hour counting. I almost finished. It's gone. 2.5 gigs at peak. Try it yourself, please.
I'm sorry, what is a CS? Is it a warranty, civil liability or is there a Japanese toy built into the terminal? )
Genetic Optimiser.
An algorithm that allows you to find an approximate solution without a complete search.
Usually a few hundred/thousand Expert Advisor runs is enough (MT has this feature)
There is just a glitch in the software.
For genetic optimisation in any memory parameter space, there is practically no memory required.
The GO is orders of magnitude faster,
There is just a glitch in the software.
For genetic optimisation in any memory parameter space, there is practically no memory required.
Same thing, only instead of 21600 I wrote 34440 runs, but it uses 10 times more memory - for 215 runs (in 8m22sec) 494Mb. are we the first to see this?
They've posted an updated build 197: they've "trimmed" the actual memory allocation in severe cases. But there is no way to pull out 57 billion.
sane, download the updated 197 build and try again, please.
In genetics, scrolling through NN billion passes of the coverage area is not a problem. The problem is in multiple visualization of results and available memory.
In any case - parameter overclocking for tens of billions has nothing to do with real optimization tasks. Our task is to perform our work with full calculations and obligatory tabular and graphical visualization, so that anyone can visually perceive the results and access any run with a mouse, for normal tasks (search area up to 2 billion variants).
Demonstrate the results of your genetic tester run right here with the same parameters you specified on the simple MACD Sample. I'm sure it won't be difficult for you to translate the code into Easy Language and show your results.