-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future todo items #95
Comments
Improve finding of min_conf sites in the "saturation phase"? Running 100k iterations showed that the RCE decreased even after 50k, but quite slowly. Finding the few "important" sites worth of optimization may take a while with our random site-selection approach. I speculate that, in the saturation phase with only few "important" sites, repeatedly executing all sites in a row (in random order), would probably improve the chances to find the "important" sites earlier. So rather than (A): "find random site & find min_conf_species" for the saturation phase I would suggest (B): bring all sites in random order and, one site after another, find min_conf_species. If done with one cycle, start at (B) again. To summarize, if for example only site #42 out of 100 sites has potential to be improved, (B) would find it within 100 steps, but (A) could need much longer. |
I am not sure (1) if I understood your idea completely ;-) Btw. after 50k iterations, the improvement was quite visible in the error plot: |
A number of suggestions:
|
A suggestion from Karel Mokany. "...non-random selection of a site in which to change presence-absences". e.g. select sites that are creating the greatest error in prediction more often. |
Add stopping criterion: I suggest having a rule like: spectre stops after no improvement in the last N iterations. Another option (less preferred by me) would be: spectre stops if improvement in the last N iterations was less than M%. The value of M should be relative, since the magnitude of error [=sum(abs(target - prediction))] depends on numbers of sites and species. Is that easy to implement, @bitbacchus ? |
This issue acts as a list of all the items we would like to implement in the future, that while not fundamental to the packages usage would be nice to have.
The text was updated successfully, but these errors were encountered: