coalescent Code

WORKSPACE DESCRIPTION

The projects in the workspace have no external path dependencie. The libraries needed are in the 'lib' directory and all paths are relative. So, the projectcan be built in a portable manner.

BRIEF PROJECT DESCRIPTION

coalescent -  It defines the object oriented architechture for population genetics problems. We try to model the concepts behind the computations. The problem domain of population genetics seems to be a nice fit for OO design. Especially, coalescent has brought many modern analysis under a common framework and it seems that an OO architechture should help in exploring more involved models as base on earlier similar but less complicated models. Typically, whenever we need to compute something, we create a prototype implementation, in groovy or in a standalone java class, and let the architechture evolve from it. The prototypes are in the project 'coalescent_prototypes'.

coalescent_app - This project contains framework code to build applications for the core project. So far we have the following applications.

 1. A console application. It is based on command design pattern. Every job has the metaphor of a command and there is a corresponding metaphor of event that describes the necessary IO for the job.
 

coalescent_lib - This project contains utility code available to all the projects in the workspace. Typically, these methods will be of small conceptual weight and are generic enough that they potentially can be used in other projects in the workspace. Additionally, each project may house a 'util' package. The rationale for it are as follows. Sometimes implementations are more general than the problems they are intended to solve, carry significant conceptual weight and are rarely of general nature that they will be used in other projects in the workspace. Such implementations are put in the 'util' package of the associated project. 


coalescent_prototype - This project has computations that were modeled using OO design in the core project. We maintain the prototypes along with the OO version because both help in progress. Prototypes have minimal dependency, typically, a single file, and consists of a single core computation. The prototypes do not model the concepts behind the equations, they just implement it. Thus, mainataining and understanding the prototype code is harder than the OO code. OO design model the concepts behind the computations and thus the algorithms become easier to understand and maintain, but, at the cost of growing dependency. Dependency is not a problem, but a necessity, but may stand in the way of improving on the core ideas of the computations. It is nice to test new core computations on the prototypes and then slowly introduce them in the OO design. It must be noted that OO design is never easy and has the risk of over-modeling. Improvements in the OO deisgn should be slow and must move its way up in steps and among those steps are, strong requirements analysis and an hierarchy of computations starting from the hand calculation to prototypes to OO design. This project also gives a no-frills look at the core computations supported by the core project. All core computations in the core project will always have the corresponding prototypes. It is worth repeating that the granularity of the prototype should be such that it helps in extending an idea rather than grouping the related items and bring OO so that you do not have to look at the implementation. We want to maintain understanding on this functional implementation and hence expressive and coincise syntax (since the algo is bare bones) are great. We are using primarily groovy but standalone java classes can also be used.

So far the following prototypes have been developed.
 
 1. Implementation of exact recursion. Given a probability recursion, compute the probability exactly by computing all the ancestral sample configurations.


DISTRIBUTION AND RELEASES

The workspace of the project can be checkedout from the svn server of the project (https://coalescent.svn.sourceforge.net/svnroot/coalescent) from sourceforge
for any revision. But typically users are interested in release versions. Revision IDs for the corresponding releases with their release notes are vailable on the project website. Release notes are incremental and contain information on the previous releases. We make two types of releases: binary and source. Binary releases are made for every major and minor version and they include the src and api besides the jar file in their distributions. Source releases are made for every maintenance version and includes the src only (no test src). All releases compile.

The following convention is followed for the release versioning . Version format is :<major_version>.<minor_version>.<maintenance_version>. 

  1. major_version: A conceptually important step is introduced. This will follow with some minor versions introducing features based on the new computation.
  2. minor_version: Under a major version it adds new functionality. 
  3. maintenance_version:  It does not change functionality, however, includes architechtural changes, API changes and improved javadoc. Note that the architechtural changes might expand the model and make future features possible but will not make those features available. 
  
So, for example, 1.0.0 would indicate a major version, whereas 1.1.0 would indicate a corresponding minor version and 1.1.1, a corresponding maintenance version.