GitLab

core/segment.cpp: KmerMultiSegmenter keeps the 'best unsegmented' kseg when the sequence is not segmented

This allows to report a more meaningful unsegmentation cause than just picking the last one.
Let say that the first point of the current CHANGELOG already included this feature.

We now store information either on lengths (on reads) or on number of reads (on clones).

We store in the 'clone_stats' member of germlines the statistics related to clones
(number of clones, number of reads per clone).

Stuttering?

ReadChooser doesn't use a file.

ReadChooser was storing all the sequences and score in a map (log-time access)
and then reads were stored in a vector which was sorted depending on the
scores stored in the map. So we had many allocations (map+vector) and a slow
access (log access time, so the sort was in n log²n, where n is the number of
sequences). I'm a bit ashamed to have done such an inefficient thing.

Now the scores and the sequences are stored in an array. The sequences
are not copied, but just a pointer to them is stored.

The C function qsort is used because the C++ sort doesn't work
(because of implicit destruction of something).

The code is now much quicker (a -c clones of 600k reads, with -z 1 is now twice as fast).

Someone motivated could probably do better with a radix sort.

For the moment the representative doesn't compute
a quality.

Since we copy the information from the best sequence if the sequence had
quality information, we were also getting it for the representative... and it
was displayed in the .vdj.fa file.

Append some flags to CXXFLAGS
and use LDLIBS instead of LDFLAGS for -lm and -lz

See https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

Affine gaps are enabled only when using some Costs such as VDJaffine.

Implements affine gaps by storing three matrices, B, Bins and Bdel.

Re-organization, equivalent code

If you would know the two most frequent affectations in a read, what could you do ?

Not using a pointer creates some problems with KmerSegmenter.
We should have a copy constructor in KmerSegmenter but it is a pain in the ***.

Not using pointers makes several copies of the same object. However the copies share the
same pointer to a KmerAffectAnalyser and that's the problem. When one of the copy is
deleted, its destructor is called which will delete the KmerAffectAnalyser and the other
copies won't have access to it, and it will also generate an error when the copies will try
to delete the KmerAffectAnalyser.

This has been solved by using pointers to KmerSegmenter everywhere.

As the 'operation' struct now contains the score, the S table is useless.

Edit operations, with their score computation and their backtracking information,
are now defined in a unique location.
The code should thus be more flexible and easier to read and maintain.

When using different indexes, this is only a cosmetic change.
But it prepares ourselves to use an unique index, possibly with a better indexing structure.