osama-raddad/encog-java

Unknown activation function

Closed this issue · 8 comments

What steps will reproduce the problem?
Store a Encog network trained and using TANH activation function.
final EncogPersistedCollection encog = new EncogPersistedCollection(file);
BasicNetwork network = (BasicNetwork) encog.find(net);

What is the expected output? What do you see instead?
The network stored in the file should be put in the network variable. But it 
returns :
Unknown activation function type: ActivationTANH

What version of the product are you using? On what operating system?
2.5.0b2 on a Gentoo box.

Original issue reported on code.google.com by androw95...@gmail.com on 5 Nov 2010 at 4:37

Hi,
I got a similar error when I was writing a web application using encog 
dependencies. It looks like a classloader issue. When I deploy war in tomcat 
and the web app tries to load an EG file, the "Unknown activation function" 
error is thrown. The following line of code would need to be fixed: 
org.encog.util.obj.ModuleHandler.createModuleList(final String... packages)

here the line:

for (final Class< ? > c : ModuleHandler.findClasses(ClassLoader
                .getSystemClassLoader(), pkgfilter, null, false, null))

uses system class loader. I think when running under tomcat the expected 
classes would not show.

Just a hunch ;-)
Would be glad to see this problem fixed ASAP

Original comment by iyerk0@gmail.com on 9 Nov 2010 at 8:27

This problem was fixed for me in the later release without changing anything.
Download the latest build at : 
http://build.heatonresearch.com/cruisecontrol/buildresults/java-encog-core

Original comment by androw95...@gmail.com on 9 Nov 2010 at 9:23

Please see attached file for fix to this issue. This works on both standalone 
and web application setups. The issue is with using system classloader. I have 
replaced it with current classloader and I got the expected results.
Hurray !

Please check attached file for fix.
Thanks

k

Original comment by iyerk0@gmail.com on 9 Nov 2010 at 10:27

Attachments:

Hi androw95220,
Thanks for letting me know. If this has been fixed, then please mark this bug 
as closed. 
One more thing can't i update to the latest core codebase from google code?
Thanks,
k

Original comment by iyerk0@gmail.com on 10 Nov 2010 at 5:53

[deleted comment]
One more thing...
Despite my changes to the classloader, the following cast fails when running in 
JUnit through an ant task

classPaths = ((java.net.URLClassLoader) classLoader).getURLs();

I suspect this will be the same issue with the existing classloader in 
modduleHandler.
I get the following cast exception
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask$SplitLoader cannot be 
cast to java.net.URLClassLoader

Note that the JUnit runs fine if I execute it from eclipse IDE directly.
FYI...

Original comment by iyerk0@gmail.com on 10 Nov 2010 at 6:19

I did make a change to address this.  For a long time Encog has resolved 
classes simply from a very long text file, that had lines like:

org.encog.engine.network.activation.ActivationSigmoid

From this text file I am able to look for the last part of the line, delimited 
by the final period.  And then use the rest of the line to resolve the line.

There were two problems with this.  First, I had to update the text file(that 
is included in the Encog JAR) each time a class is added or removed.  Second, 
if Encog attempted to persist a user class, it did not work.  Because the user 
class was not in the text file/

A user contributed the class loader, it read the JAR and dynamically built the 
class list.  This seemed good, as it solved both of the previously mentioned 
two problems.  

But I was getting reports of Encog not finding the activation function.  I 
reimplemented the classpath text file, with the module loader as a "fall back". 
 So, if you are using an Encog standard activation function, then Encog SHOULD 
find it in the class file, without the need to use the module loader.  However, 
if the class is not in Encog's built in class list, then the module loader is 
used.

I will take a look.

Original comment by heatonre...@gmail.com on 11 Nov 2010 at 1:09

Original comment by heatonre...@gmail.com on 18 Nov 2010 at 2:52

  • Changed state: Verified