[Dynamite] Is this working now then?

[Ian Holmes]

On Sun, 5 Mar 2000, Guy Slater wrote:

> I would have thought you wouldn't need any identifiers for the DP itself,
> but only for alignment display, database searching, etc.
> 
> Again, I think we need to have a list of all objects,
> to make it easier to mark out the territory of each of them ...

Maybe not a super-exact-final-ultimate-no_more_changes list, but 
definitely some discussion of the object boundaries.

Often what starts as one object can split into several very similar
objects (witness Sequence). With that caveat, I reckon we need the
following "objectoids": ("objectives"? "objections"?)

(1) Model descriptors

- SingleHMM, PairHMM, PolymerHMM
   ... these specify the topology of the models

- SingleParameters, PairParameters, PolymerParameters
   ... these specify the parameterisations of the models
   ... these should probably be interfaces rather than data structures,
   ... so that we can e.g. provide a wrapper class that maps "gap_open"
   ... & "gap_extend" to the appropriate transitions in a Needleman-Wunsch
   ... model

(NB I think all alignment algorithms should be global at the minute. Doing
local alignment is effectively an optimisation step, equivalent to saying
that some cells are zero throughout the matrix)

(2) DP algorithms & results

- SingleViterbiAlgorithm, PairViterbiAlgorithm, PolymerViterbiAlgorithm
   ... these return an alignment & a log-likelihood
   ... my feeling on alignments is much the same as my feeling on
   ... sequences: the base alignment class should be VERY simple,
   ... probably just a sequence<int> describing the state path through the
   ... HMM. We can get additional functionality by inheriting.

- SingleForwardBackwardAlgorithm, etc.

- SingleCounts, PairCounts, PolymerCounts
   [and possibly SingleDerivatives, PairDerivatives, PolymerDerivatives?]
   ... these are datastructures returned by the Forward-Backward algorithm

Ian