v4.0.0

2021-09-22 Redmar van den Berg

• Version 4.0.0: Update FuMa to Python3 (see issue #46)

Compatibility with PyPI

Remove the author email placeholder, since PyPI checks for a valid email address.

v3.0.7

2021-08-11 Redmar van den Berg

• Version 3.0.7: HOTFIX for issue #43 - Thanks @Redmar-van-den-Berg

v3.0.6

2020-05-06 Youri Hoogstrate

• Version 3.0.6: Support for ARRIBA - thanks to Alexandre Rouette

v3.0.5

• Deployment updates
• Two fixes in export function (no change in output)

v3.0.3

API Changes, only useful for tools depending on FuMa as lib

v3.0.2

• Suppresses a warning seen in some installations

v3.0.1

• Added a simple break statement that ensures the output is in the order of the number of datasets in which a fusion gene is being found.
• The logging function now does not skip the 100.0% which was caused in some cases occured due to a rounding artefact.

v3.0.0

The core has been rewritte because it needed to use much
less memory for a large number of datasets. Initially the code created
sub datasets, because it was expected to export them time-wise and it was
very handy for running unit tests and for creating the summary output.
This resulted in a very high memory consumption for a large number of
experiments (not with respect to the number of total Fusion genes).
The rewritten code consumes memory in relation to the total number of
Fusion objects. However, for the summary output we still use the legacy
code and for the list output we make use of the new code.

FuMa now starts with a n*n (num Fusion objects in all experiments)
triangular matrix in which it compares all fusions with any other fusion
gene. If they are considered identical, a MergedFusion object will be
stored for the next iteration. Otherwise, at the end of the iteration,
all non matched fusion genes will be exported to file.

For the remaining MergedFusion genes, FuMa will create a m (number of
MergedFusion objects) * n square matrix and compare whether the Fusion
genes matches the Merged fusion genes. Again, if they are identical,
they will be kept for the next iteration (these MergedFusion objects
will contain 3, 4 or more original Fusion objects each) and those that
are not being matched will be exported to file. For those that will be
kept for the next iteration, 'duplicates' will be removed. If no matched
objects remain, FuMa is finished.

Because of this update, for analysis with a low number of samples and a
high number of fusion genes, FuMa may have become (quite) a bit slower.
However, we believe the cost of some extra running time is much and much
more desired than the exponential memory requirements.

Important:
We have also found and resolved a small bug. In older versions of FuMa,
indexing was chromosome-name based. Therefore matching two fusion genes
only happened when they were annotated upon the same chr name. If you
would have a fusion gene A-B (both on chr1) and fusion A-B (both on
chr2), the old versions would consider these distinct whereas the new
version of FuMa considers these identical.

Important 2:
We have found another minor bug. In rare situations where no fusion
gene was matched, the original fusion genes were not reported but
such that the number of input files did not equal the number of
output files (test_OverlapComplex 08_b and 09_05 and many in test 10).
This bug has been resolved in v3.

v2.12.3

• Fixed a bug that may cause abnormal termination if --acceptor-donor-specific-order is enabled