You are here

Home » Neural Network Forums » Encog Project » Using Encog in Java

Resources for extending Encog?

RobertCoop's picture
published by RobertCoop on Sun, 08/19/2012 - 19:57

I am looking to use Encog for a research project, and will need to extend several aspects of Encog in order to allow for new network types and training. Are there any resources/design principles/architecture details available to assist with this sort of work?

Also, I saw a comment somewhere else, but I am wondering about the many 'final' methods in the source. Is there still a current need for these? I'm currently cloning the git repository and making local changes, but I'd love to hear some sort of 'official' opinion on why they are there...

Neural Network Forums: 
Using Encog in Java
jeffheaton's picture

Submitted by jeffheaton on Mon, 08/20/2012 - 10:22.

The large number of "final" methods are the result of using too strong of a setting on InteliJ's code cleanup utility. I plan on removing most of them in the 3.2 release of Encog. It does prevent you from extending Encog.

I know there is a "school of thought" that says every method should be final to control inheritance. Which is why this is a common autocorrect feature in many IDE's. uBut this is a restriction I plan to lift.

Leonid's picture

Submitted by Leonid on Mon, 08/20/2012 - 10:47.

I've already moved most many of them. If you like, I can send a pull request?

jeffheaton's picture

Submitted by jeffheaton on Mon, 08/20/2012 - 15:14.

Sure, if you already have that complete, please send. Thanks!

Leonid's picture

Submitted by Leonid on Mon, 08/20/2012 - 16:17.

All ready four you to approve!

matka's picture

Submitted by matka on Tue, 08/28/2012 - 11:10.

Jeff,
Can you include this in the 3.2 snapshot?

rchillyard's picture

Submitted by rchillyard on Mon, 03/04/2013 - 11:18.

This raises an interesting point. Methods that, if changed, would break the software should be final (if public). Most such methods should probably be private anyway. By its very definition, a "framework" should generally make every public (and of course protected) method non-final. There might occasionally be an issue with polymorphism causing unnecessarily inefficient dynamic binding at runtime but I doubt if that would ever be an issue. If it was, an alternative method could be provided which is final. I note that 3.1 has many finals removed and am looking forward to 3.2.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer