Re: [Math] Review of "genetic algorithm" module
Hi All
Please find my comments below:
>I've merged PR #208 into the feature branch (please open a
>new one for changes entailed by the comments below).
>I again had to delete the branch (and recreate it with the merged
>changes from PR #208). [I must be missing something about the
>correct git workflow...]
-- I have taken the latest code from apache repo.
>There seems to be something wrong in the "examples-ga-tsp"
>application (fitness does not change).
-- I have fixed the issue in fitness function calculation.
>At the end of the run, one should be able to quickly assess the
>goodness of the solution; the new code prints a line with many
>"Node [...]" elements while the "--legacy" switch prints the "best"
>fitness and a list of indices. In either case, the solution should
>consist of the list of visited cities (one per line) and the total
>distance.
-- I have made the changes.
>I can't seem to find how the logger is configured. Currently, all
>"INFO" messages are logged to the "standard error" console; one
>should be able to e.g. redirect output to a file, or set the log level.
-- There is a dependency for "slf4j-simple" in the "examples-ga" module
which would print all log messages in the console. There was a discussion
earlier on this and the decision was to use console for example modules for
log messages. Library users would add the implementation of slf4j according
to their need and provide required configurations to control the log levels
and messages.
>
>There is still a mix between library code and application code (but
>this is to be discussed in MATH-1643.
-- Kindly update the JIRA with your suggestions.
>From browsing the library code, I'm tempted to believe that the
>dependency towards a logging framework is not necessary (or
>underused).
-- Do you mean dependency on the slf4j?
I think that such a feature could be left to the application
>layer (per the "ConvergenceListener" registry).
-- ConvergenceListener is only to log the nature of convergence,
not internal details of all operators. Currently we have a very low number
of log messages which can be increased later.
>Likewise, the "PopulationStatisticsLogger" is not general enough to
>be worth being part of the library.
-- I would love to keep this simple implementation of convergence listener.
This can provide a very basic overview on the nature of convergence.
>A few (nit-pick) remarks about code style in general.
>Javadoc is incomplete: All methods must be documented.
>Please avoid redundant links like e.g.
>---CUT---
>/**
> * @param crossoverPolicy The {@link CrossoverPolicy}
> * @param mutationPolicy The {@link MutationPolicy}
> * @param selectionPolicy The {@link SelectionPolicy}
> * @param convergenceListeners An optional collection of
> * {@link ConvergenceListener} with
>variable arity
> */
>@SafeVarargs
>protected AbstractGeneticAlgorithm(final CrossoverPolicy
crossoverPolicy,
>final MutationPolicy mutationPolicy,
>final SelectionPolicy selectionPolicy,
>ConvergenceListener... convergenceListeners) {
>this.crossoverPolicy = crossoverPolicy;
>this.mutationPolicy = mutationPolicy;
>this.selectionPolicy = selectionPolicy;
>updateListenerRigistry(convergenceListeners);
>}
>---CUT---
>Readers of the HTML-generated doc can already click on the various
>arguments within the signature; so there is no need to add visual noise
>in the source code just to be able to click from within the Javadoc part
>just above that signature.
>The Javadoc block above should be
>---CUT---
>/**
> * @param crossoverPolicy Crossover policy.
> * @param mutationPolicy Mutation policy.
> * @param selectionPolicy Selection policy.
> * @param convergenceListeners Collection of user-defined listeners.
> */
>---CUT---
>[Note the absence of "The" and the presence of a final "period".]
>
-- Are we following this standard in the commons-math project? This would
initiate changes in almost all classes.
>A blank line is welcome to separate ideas ("logical" blocks of code)
>However, there should not be an empty line after a closing brace if
>it is followed by another closing brace.
>Also, in all recent codes, there is no blank line between the instance
>fields; the (mandatory) Javadoc is enough to logically (and visually)
>separate the fields.
-- I have rectified this.
>
>In "AbstractGeneticAlgorithm":
>* There should be a single constructor (handling default values should
> be left to the application layer). [This would allow the removal of
> "updateListenerRigistry" method (note: There is a typo in that name).]
--This is corrected.
>* Are annotations (@SafeVarargs, ...) necessary? Please document.
-- This annotation is necessary for any parameterized vararg. This is also
used in legacy classes like o.a.c.m.l.a.i.FieldHermiteInterpolator and
Re: New component proposal: commons-plugins
Hello, I don’t think plug-ins is something which fits well in the scope of commons, as it does tie into a broader ecosystem/platform normally. but I could be wrong. Btw: Commons VFS has a plug-in system, mostly for providers. Gruss Bernd -- http://bernd.eckenfels.net Von: Ralph Goers Gesendet: Monday, April 11, 2022 12:00:12 AM An: Commons Developers List Betreff: Re: New component proposal: commons-plugins See below > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote: > > Thanks Ralph for the detailed explanation. I appreciate it and now I see > the points. I’ve removed the parts that I don’t think need any more discussion. > - How will it be a “plugin" project and not another dependency injection > framework? This is a great question. I think the main difference is with examples like Log4j and Apache Flume, and even Apache Maven. All wire components together via user provided configuration, not code. Dependency injection could certainly be part of the plugin framework but that would be for implementors of plugins, not the users using them. Users of Maven don’t know that Plexus is used under the covers and neither should users of a commons-plugins implementation. > - What will distinguish it from module systems, like OSGi and what will > stop it from becoming another OSGi by the years as new features get added > to the library. OSGi is complicated. Implementing plugins should not be. Just as I described using ServiceLoader to locate plugins, plugins should also be accessible in OSGi bundles. Users should be required to do as little as possible to adapt the plugin system to the environment it is running in but plugins shouldn’t know or care anything about how they are located and loaded. Plugins are also to the application or framework that will be using them. They essentially define what the valid plugin types are and where they can be used. > - What applications using plugins are the examples for different solutions? > (Log4j is a good example to show that there is a need, you also explained > patiently why it is not a simple ServiceLoader, but it is only one way to > solve it. Other applications may approach the issue differently. Maven, > Attlassian products, other build tools, JUnit 5 and so on.) We’ve already mentioned Log4j. Apache Flume also sort of supports plugins, which I previously mentioned. The main ones are Sinks, Channels, and Sources. In the Flume configuration Sinks provided by Flume can be referenced by their “simple” name because they are manually registered in the code. User provided components have to provide the whole fully qualified class name to be located. In addition, Flume components must locate their own configuration. This limits the format the configuration can take. For example, Flume currently uses properties but I would like to support JSON and YAML Due to the way property support was implemented it is difficult to support either of those without impacting users who have built custom components. This is where using injection does help. The plugins would be insensitive to the configuration format so making changes would just require changing how the configuration binds to the plugin system. > - Based on the gathered knowledge on the previous point, what is the high > level architecture of a plugin system the library will support and what > services will it provide? I think that is TBD. Although we have suggested starting from Log4j’s code, that isn’t a requirement. I would suggest that some experimental code be placed in a project and then whoever is interested can collaborate and debate the pros and cons. That is exactly how Log4j 2 got started. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New component proposal: commons-plugins
See below > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote: > > Thanks Ralph for the detailed explanation. I appreciate it and now I see > the points. I’ve removed the parts that I don’t think need any more discussion. > - How will it be a “plugin" project and not another dependency injection > framework? This is a great question. I think the main difference is with examples like Log4j and Apache Flume, and even Apache Maven. All wire components together via user provided configuration, not code. Dependency injection could certainly be part of the plugin framework but that would be for implementors of plugins, not the users using them. Users of Maven don’t know that Plexus is used under the covers and neither should users of a commons-plugins implementation. > - What will distinguish it from module systems, like OSGi and what will > stop it from becoming another OSGi by the years as new features get added > to the library. OSGi is complicated. Implementing plugins should not be. Just as I described using ServiceLoader to locate plugins, plugins should also be accessible in OSGi bundles. Users should be required to do as little as possible to adapt the plugin system to the environment it is running in but plugins shouldn’t know or care anything about how they are located and loaded. Plugins are also to the application or framework that will be using them. They essentially define what the valid plugin types are and where they can be used. > - What applications using plugins are the examples for different solutions? > (Log4j is a good example to show that there is a need, you also explained > patiently why it is not a simple ServiceLoader, but it is only one way to > solve it. Other applications may approach the issue differently. Maven, > Attlassian products, other build tools, JUnit 5 and so on.) We’ve already mentioned Log4j. Apache Flume also sort of supports plugins, which I previously mentioned. The main ones are Sinks, Channels, and Sources. In the Flume configuration Sinks provided by Flume can be referenced by their “simple” name because they are manually registered in the code. User provided components have to provide the whole fully qualified class name to be located. In addition, Flume components must locate their own configuration. This limits the format the configuration can take. For example, Flume currently uses properties but I would like to support JSON and YAML Due to the way property support was implemented it is difficult to support either of those without impacting users who have built custom components. This is where using injection does help. The plugins would be insensitive to the configuration format so making changes would just require changing how the configuration binds to the plugin system. > - Based on the gathered knowledge on the previous point, what is the high > level architecture of a plugin system the library will support and what > services will it provide? I think that is TBD. Although we have suggested starting from Log4j’s code, that isn’t a requirement. I would suggest that some experimental code be placed in a project and then whoever is interested can collaborate and debate the pros and cons. That is exactly how Log4j 2 got started. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
