Releases: nanoandrew4/Genetic-Circles
Fixed minor typo
Fixed minor typo in Main.java help.
Optimization and input overhaul
Optimized algorithm to run faster. Also tweaked some output to make it more helpful.
Overhauled input system: Much easier and dynamic, all variables can be modified easily. See README for more info, or run program without arguments to get help.
This release uses code from commit 6f39c02
Minor bug fix in displaying runtime
Fixes bug that did not allow for integers less than 2 when displaying run time. This means that if the program ran for 1 minute and 1 second, the program would display the run time as 1 second. Run time is now accurate, this is a minor fix and has no impact on any other part of the program.
Commit with this fix: 374b56c
Removed voronoi diagram usage
As per commit 958e6ee, voronoi diagram usage has been removed and the algorithm now performs a blind search for the best circle.
The new method involves a variable called badGenerations. This variable specifies when to end the algorithm. If for example, badGenerations = 5000, and the best circle found is from generation 3000, the algorithm will stop at generation 8001 if no better circles are found before then. If for example, the next best circle is found at generation 4000, then the algorithm will plan to end at generation 9001 unless a better circle is found before then, and so on. The bigger the badGenerations value the more accurate the largest circle will be, but the longer it will run.
Aside from that, cleaned up some code and tweaked some settings. The input for the program is still flimsy but that will be fixed soon. Also, the README is not compatible with this version. A new one will be put up soon.
Bug fix for headless systems
Fixes a bug which does not allow the program to launch in a headless system
File writing + Multi-Threading!
This release adds two new improvements to the program, and fixes one major bug that went undetected in the previous release.
The first of the improvements is the addition of multi-threading in the DataCollector class. While previously all iterations of the Genetic algorithm had to be computed on one thread, now the load can be spread to use all but once threads that are available. So if you are rocking a quad core, that is a 3x time improvement! And worry not, all threads are not created at once, instead when once finishes another starts, thus liming active threads to all available threads minus one (so that the child threads don't compete with the main program handling all the thread creation and management.)
The second improvement is the addition of the option to write the output of the DataCollector class to a file for later inspection and testing. Output naming convention is as follows: GeneticCircles-iterations.txt where runs is the number of iterations of the genetic algorithm.
Both main classes have been joined in one, and now both graphical and non-graphical mode launch from the same binaries. Run the program with no arguments to see usage, or check the README of this project.
Initial release
This release includes java files for the basic algorithm. If the UI version is run, it will draw the first circle that has at least 97% the radius of the largest possible circle computed by the voronoi diagram. Although sometimes the algorithm will run longer than others, it should not run past 500k generations, and in the event it does, just give it some time. Most runs don't even breach 200k generations.
If running the headless version, the DataCollector class will be launched instead of Main. Functionality is the same as the UI but runs with no graphics, and still computes to 97% minimum size of the largest computed size by the voronoi diagram. What this means is that the program will run the algorithm 50 times, with seed values for the random number generator starting at 0 and ending at 49. With each run, it will output the seed used, the final generation that contained the valid solution, the radius and the proximity the final solution had to the solution computed by the voronoi diagram.
Note that the largest possible radius computed by the voronoi diagram is not always the biggest radius. Sometimes the voronoi diagram returns a max value that the algorithm surpasses, therefore giving it a proximity value of over 100%