DEV Meeting 1

The Alignment Module

• There will only be one global function called align_pairwise(range1, range2, config)
• All the configuration that you can think of will be specified in the config object, e.g. banded, affine gaps, soring schemes, SIMD, etc ...
• Many configurations will internally resolve to static 'policies' (e.g. the affine_policy that knows it must store 3 scoring matrices)
• The policies will determine the behaviour of the alignment_kernel (the alignment_kernel struct inherits all policies)
• and the alignment_kernel struct will be the central instance of the alignment algorithm and have an operator()(range1, range2, config) that finally computes whatever alignment you want it to.

Refactoring of the Alphabets:

In case you did not review the PR, here are the main things that changed:

• The individual alphabets now inherit from an CRTP alphabet base class which avoids a lot of redundant code
• The alphabets are still trivial data types but no POD's anymore (as they now have custom defined constructors)
• The cartesian_composition formerly combined two alphabets by storing a tuple. It now combines the alphabets and stores only a single rank value. It still has the get interface to query values of the individual alphabet though.
• We now have a proxy base_class for alphabets that inherits from alphabet_base and ensures that the proxy will also fulfil the alphabet concept.
• There is NO literal namespace anymore (once the PR is merged).
• You will now specify out alphabets by literal instead of a static variable. e,g, 'C'_dna4 instead of dna4::C.

File Output

In general, we will not test the given user variables before printing them out. The user has to take care of producing correctly formatted files. For example we will not check for the new line character in the FASTA identifier (id) which would corrupt the file. If you feel that certain things would be helpful to test or you encountered errors, add debug asserts.