JGAP is a genetic algorithms and genetic programming package written in Java.
JGAP version 3.01 adds grid functionality to the code base of release 3.0. With that you can build your own grid in LANs.
A grid hosts a server, one to many workers, and one to many clients. A client can send work requests to the server, which in turn splits the work and provides the workers with corresponding tasks. After a worker finished a task the result is sent back to the server, which finally sends each received result back to the requesting client. The package used for grid functionality is jcgrid, another open source project.
This release can be downloaded here:
http://sourceforge.net/project/showfiles.php?group_id=11618&package_id=48940
For more information visit http://jgap.sourceforge.net
Stuff related with sort of evolutionary or innovative concepts and architecture in the field of Java
25.9.06
1.9.06
JGAP 3.0final released
Today, JGAP 3.0final has been released. JGAP is a genetic algorithms and genetic programming package, which is easy to use and which is delivered with ready-to-use components, such as genetic operators, selectors and examples.
Try it out now, this version contains many improvements.
Feedback is very welcome :-)
Try it out now, this version contains many improvements.
Feedback is very welcome :-)
3.6.06
German JUnit book released
Just these days my junit book was released and can be ordered at Amazon.
Information about the book can be found at the book's official homepage.
As said, the book is written in German, but maybe some of you can handle this :-) The homepage contains some information about it and links to some english articles that may be of interest.
Information about the book can be found at the book's official homepage.
As said, the book is written in German, but maybe some of you can handle this :-) The homepage contains some information about it and links to some english articles that may be of interest.
25.5.06
Faster than light... this time not with Java
Isn't that awesome! Light can predict the way it will take (or, to adapt this statement to the new findings: ... it had taken in future).
Quantum physics has not been mentioned in the article but it is definitively sort of issue QP will have to cope with.
This is not related to Java in any way but it's so gorgeous that it's worth an entry :-)
Quantum physics has not been mentioned in the article but it is definitively sort of issue QP will have to cope with.
This is not related to Java in any way but it's so gorgeous that it's worth an entry :-)
28.4.06
JGAP 2.6 released
Some days ago, JGAP 2.6 has been released. JGAP is a genetic algorithms package, which is easy to use and which is delivered with ready-to-use components, such as genetic operators, selectors and examples.
Try it out now!
In the CVS you already find code to solve problems using Genetic Programming (see directory gp-src).
Feedback is very welcome :-)
PS: The German junit book references JGAP several times when it comes to sample projects utilizing JUnit.
Try it out now!
In the CVS you already find code to solve problems using Genetic Programming (see directory gp-src).
Feedback is very welcome :-)
PS: The German junit book references JGAP several times when it comes to sample projects utilizing JUnit.
19.4.06
Common Annotations for Java (JSR 250) shamefully approved
After several protests of mine to avoid the finalization of JSR 250 (Common Annotations for Java), now the Executive Commitee has shamefully approved that JSR.
Thanx Doug Lea for adding a comment to his vote the first time I can remember. He wrote: "Underwhelming but innocuous". Then, Doug, you better voted with "No", please. That would have raised your reputation a lot...
Anyone, please read the lousy specification and judge for yourself. Or, as Apache Foundation commented its vote: "I hope there's enough production-tested, real-world experience behind this... :)".
I think there's a general problem with the JSR process (or the EC members) if the committee members vote as they did yesterday!
Thanx Doug Lea for adding a comment to his vote the first time I can remember. He wrote: "Underwhelming but innocuous". Then, Doug, you better voted with "No", please. That would have raised your reputation a lot...
Anyone, please read the lousy specification and judge for yourself. Or, as Apache Foundation commented its vote: "I hope there's enough production-tested, real-world experience behind this... :)".
I think there's a general problem with the JSR process (or the EC members) if the committee members vote as they did yesterday!
10.1.06
Anybody using JUnit's ExceptionTestCase ?
To write a unit test that expects an exception of a particular type to be thrown is possible by using JUnit's class junit.framework.ExceptionTestCase. However the usage of this class (that inherits from junti.framework.TestCase) is ugly (details such as import statements omitted):
1. Test class
2. Test suite
I've never ever seen such a stupid thing. Maybe that is the reason for ExceptionTestCase currently not being existent in JUnit 4's CVS version.
1. Test class
public void MyTestCase extends ExceptionTestCase {
public void testXYZ throws Exception {
MyClass myObj = new MyClass();
myobj.doXYZ(); //throws MyException
}
}
2. Test suite
public void MyTestSuite extends TestSuite {
public static Test suite() {
TestSuite suite = new TestSuite("description");
suite.addTest(new MyTest("testXYZ", MyException.class));
return suite;
}
}
I've never ever seen such a stupid thing. Maybe that is the reason for ExceptionTestCase currently not being existent in JUnit 4's CVS version.
Also see the JUnit book for further information.
Subscribe to:
Posts (Atom)