Hello. Le sam. 15 oct. 2022 à 16:39, Avijit Basak <avijit.ba...@gmail.com> a écrit : > > Hi All > > Please see my comments below. Kindly share further thoughts. > > > [...] > >I'm not sure what you mean: The examples just run a GA-like algorithm, > >but (AFAICT) do not compare the output to some expected outcome. > -- I have some code changes in the "examples-ga-math-functions" module to > compare results of two modules "commons-math4-ga" and "commons-math4-ga2". > A graphical approach using JFreeChart has been adopted for the same. A new > value "COMPARE" has been introduced for the "--api" input argument to > initiate the comparison.
I think that I already raised the issue of "fancy" output not being the most appropriate choice for developing things here; GUI especially tend to become outdated fast, and we are left with cruft code to update to <whatever> is the new trend (a few months ago, I had to remove GUI examples for the clustering functionality). It's great if the component contains tools that help in debugging, but those should be text-based (see e.g. the benchmarks and stress tests infrastructure in "Commons RNG"). Otherwise, debugging is performed on the developers' own computers and information is collected in JIRA (where you can post pictures which you have created locally). Please do so (you are welcome to create a dedicated report) so that we can make progress, on this particular point, from concrete elements. > The "commons-math4-ga" module consistently provided better results than > "commons-math4-ga2". > The code is kept in my repo > https://github.com/avijit-basak/commons-math/tree/feature/MATH-1563_comparison > . > I did not raise a PR till now. This is only kept in my repo for comparison. > Could you please check if the feature__MATH-1563__genetic_algorithm branch > does contain changes from master of apache repo. I'm not sure what you mean here. I tried $ git rebase master within the feature__MATH-1563__genetic_algorithm branch. But I after I fix the conflicting files, and issue $ git rebase --continue I'm getting more and more conflicts in Java files in "common-math-ga" module; since those are supposed to only exist in the "feature" branch, I don't know what's going on. A local problem on my machine? > [...] > > > > >[1] My main argument for the "GA variant" is that it is much simpler, for > > what seems equivalent functionality (bugs, or misinterpretation of > > expected behaviour, notwithstanding): Current counts of lines of > > code is 696 vs 2038. > -- The variant only contains options for binary genotype but the > "commons-math4-ga" module provides options for other genotypes too. So, we > may not compare the lines of code. Yes we can. Even removing the code in package "chromosome", there are quite many more lines in module "commons-math-ga". Also, there is a lot of code dedicated to managing the representation of "binary" chromosomes whereas, in "commons-math-ga2", I've used the JDK "BitSet". > However, considering the optimization > result and options of genotypes I noted from the outset (cf. ML archive) that I didn't implement the other genotypes, since my point was only to provide a "proof of concept" about how to fix the (implementation) issues which I had with the code in "commons-math-ga". I've always known that functionality is lacking in "commons-math-ga2", but I was expecting that you'd fill those gaps (genotypes and unit tests) once we'd agree that your initial implementation was unnecessarily complex (one measure of it being the line count). > I would still vote for "commons-math4-ga" > instead of its new variant. The question does not come in these terms (i.e. one or the other, in the state that they are now). Rather, we'll have to converge to a piece of code that is both correct (i.e. provide the results which you expect) and maintainable (i.e. free of the "commons-math-ga" issues which I've fixed in "commons-math-ga2"). Hopefully your analysis on JIRA will uncover the bug(s) that entail the problems which you are observing. They can then be fixed and we'll get the "best of both worlds". Regards, Gilles > > > > [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
