
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
I suggest that population size should be calculated:
Thank you so much for the article! If not for it - I never learnt what genetic methods are :)
But there is one question! When we check chromosomes from the database - in case of a match - one unit will be subtracted from the chromosome index from the database. Why? And what if the index is zero?
Where am I wrong?
I suggest that population size should be calculated:
I will not dispute the competence of the cited source, but I have to disagree.
The feasibility of using GA in optimisation problems lies in reducing the number of FF runs required to determine the optimum compared to direct search.
If we follow the recommendation
ChromosomeCount=GeneCount*11;
the problem with 1000 arguments will require a population size of 11000 individuals! And that's 11000 FF runs on only 1 epoch! You can just as well use random gene generation and the result will not be much inferior in finding the optimum. The given source makes a "bet" that in a large population there will be enough genetic material to further develop the population towards improvement at each epoch. I am trying to achieve the same thing, but by playing probabilities with genetic operators without total increase of FF runs.
Thank you so much for the article! If not for it - I never learnt what genetic methods are :)
But there is one question! When we check chromosomes from the database - in case of a match - one unit will be subtracted from the chromosome index from the database. Why? And what if the index is zero?
Where am I wrong???
The database is only checked if there is at least one chromosome in the database. You didn't cite the entire section of the database search code.
Therefore, the case when there are no chromosomes in the database but the groove is checked is impossible.
The database check is performed only when there is at least one chromosome in the database. You have not given the whole section of the code for searching by base.
Therefore, the case when there are no chromosomes in the database, but the groove check is performed is impossible.
Thank you for such a prompt reply! I didn't mean exactly what you are talking about!
1) Suppose that there is indeed one chromosome in the database (ChrCountInHistory = 1 - i.e. the array dimension is equal to one) - then its index in the database is zero! (ChrCountInHistory is zero by default - the index of an element in the array is zero).
And we subtract one from this index:
besides, the search starts from Ch1=0.
2) We compare with HistoryHromosomes[Ge][Ch1 ], and assign HistoryHromosomes[0][Ch1-1].
You're right, thank you.
That's the way to do it:
You're right, thank you.
That's the way to go:
Hmm.
Now"Array out of range" on HistoryHromosomes[0][Ch1], although everything seems to be correct...
joo:
You're right, thank you.
You're welcome! The main thing is that it works even better now than before :)
joo:
Hmm.
Now "Array out of range" on HistoryHromosomes[0][Ch1], though everything seems to be correct...
It's hard to say why - we have different code to analyse. Maybe it's the "position" variable - its analogue in the article is "chromos". I've looked through the code in the article probably 10 times - I couldn't understand where the bug is :( I'll check later on the examples in the article - maybe something will become clearer.
P.S. : it is justified to use a memory bank if a variable consists of ~150 values. And there are 100000 individuals in the history. Maybe in such a case it would be faster to calculate than to check (search) it all? You haven't checked it?
P.S. : it is justified to use a memory bank if a variable consists of ~150 values. And there are 100000 individuals in the history. Maybe in such a case it would be faster to count than to check (re-check) it all? You haven't checked it?
It all depends on the time required to calculate the FF. If the FF is just some mathematical function, then the bank is not reasonable. But if the FF uses history runs (neuron learning, etc.) and other resource-intensive tasks, then the bank is necessary and can significantly reduce the optimisation time.
Well, it also depends on the accuracy of genes. The "coarser" the genes are, the more often repetitions will occur, and the more reasonable it is to use a chromosome bank.
....
:)
Still, there is no error, you confused me a lot. Here, I've made a test script, try it out, you'll understand everything.
Here, although it compares the chromosome with the position of Ch1, but on the upper loop it is assigned +1, so I subtract -1 afterwards.
I agree, it's a bit crooked, it could be done better.
Here is a script to check it: