Exposing parameters of the training algorithms

[gnitr]

This is a feature request.

It would be helpful to expose the parameters of the training algorithms with setters and getters.

Take RProp for instance (TrainFlatNetworkResilient). Some of the parameters can be set via a call to the constructor. But after that there is no way to get their value. And since those parameters are also declared as private, there is no way for a new subclass to change the behaviour of the training algorithm.

Other parameters like RPROPConst.POSITIVE_ETA and RPROPConst.NEGATIVE_ETA are constants. When doing research, it is often important to run many trials with a range of possible values for the heuristics in order to find the best combination. In this case it is only possible to do it by changing the value of the constants in Encog's source file.

Going a step further, it would be even better in a future release to expose those parameters more dynamically. By that I mean a standard interface for obtaining the list of the parameters, their name, description, value and possible range. This would be allow a UI to work more dynamically with the algorithms. It would also allow to log information about a training algorithm and its exact settings to a file so an experiment could be properly documented and reproduced.

[gnitr]

The idea of exposing information about the heuristics with a standard interface would also allow evolutionary algorithms (like GA or ES for instance) to automatically optimise them along with the network weights.

[jeffheaton]

Sounds like a good idea, I am assigning to 3.1.

[nicholas-jordan]

I gave a lot of thought to the get/set paradigm "a while back" and realized the power of what professionals call a "static factory method" ~ it was needful to do a boolean on the call to eliminate ambiguity that derives from get / set "call pair" - if we do not "trap" it at a functional level what we end up with is what I have come to call "an intrusion portal" ( aka failure zone )

having been in the shop where things run it became apparent to me the way to implement the sort of interface being discussed here is:

// psuedo-code final static synchronized Object < type > access ( boolean getSet ,.....

then write the code returning non-null or throwing on the overall design - forcing the use of boolean determinant results in evaporation of code-bloat