Moving QuiverRows to Algebroids

[zickgraf]

I suggest moving the code of QuiverRows and the corresponding tests to Algebroids. Rationale:

1. QuiverRows is a compiled version of the tower AdditiveClosure( Algebroid ). Towers should either live besides their base (i.e. Algebroid), if it semantically fits, or in a separate package. Putting towers together with their top part (i.e. AdditiveClosure in this case) would massively clutter packages which implement abstract, higher concepts.
2. Algebroids currently runs all the tests of FreydCategoriesForCAP to cover the tests which need QPA, although the latter only comprise a very small part of the tests.
3. We could avoid the suggested dependency of FreydCategoriesForCAP on QPA2, which causes issues now and then.

@sebastianpos @mohamed-barakat Would you be fine with this change?

[zickgraf]

HigherHomologicalAlgebra does not use QuiverRows anymore. The only remaining users are:

1. Some examples/tests in FreydCategoriesForCAP.
2. Benchmarks in Algebroids comparing QuiverRows to AdditiveClosure( Algebroid ). I would like to keep those for now as regression tests for CompilerForCAP.

@sebastianpos Would you be fine with moving QuiverRows (including the tests) to Algebroids?

[sebastianpos]

I'm not sure. Algebroids is not within the CAP_project repository, and it seems that Algebroids has other dependencies than FreydCategoriesForCAP, which will make using QuiverRows more demanding.

But maybe I don't want to use QuiverRows anymore? Could you maybe update me on the functionality of the compiled version of AdditiveClosure( Algebroids )?

[zickgraf]

But maybe I don't want to use QuiverRows anymore? Could you maybe update me on the functionality of the compiled version of AdditiveClosure( Algebroids )?

Both basically have the same operations installed: the only operation QuiverRows has which is missing from AdditiveClosure( Algebroids ) is AdditiveGenerators. There also are some differences in the set of primitively installed methods but those should be minor. The homomorphism structure on morphisms of the compiled version of AdditiveClosure( Algebroids ) is more than 60% faster than QuiverRows, at least in artificial tests with random morphisms: https://github.com/homalg-project/Algebroids/blob/c61859939d74af922d5582c5bf1671d6cc4fe48e/tst/AdditiveClosureOfAlgebroid_vs_QuiverRows.tst In real-life examples the improvement is probably not as significant, but still should exist.

Since the data structure of AdditiveClosure( Algebroids ) is more complex than the one of QuiverRows, cheap operations like AdditionForMorphisms might be a bit faster when using QuiverRows. If this overhead is relevant for your applications, compiling your code will give a significant speedup. Since QuiverRows is not compilable currently, you would also want to use AdditiveClosure( Algebroids ) in this case.

[sebastianpos]

Thanks, this sounds good. And ok, you can move QuiverRows.

Are there plans for moving the Algebroids package into the CAP_project repository?

[mohamed-barakat]

Are there plans for moving the Algebroids package into the CAP_project repository?

The current plan is to move Algebroids and other category constructors to the new mono-repo CategoricalTowers. Each subdirectory should ideally contain a single constructor.

[zickgraf]

Done with #1208 and homalg-project/Algebroids#227.