Ring and CommRing
Currently all commutative ring types belong to
Ring and their elements to
RingElement) and we have separate types for noncommutative rings and elements thereof, i.e.
However, it would be more logical to use
Ring for not necessarily commutative rings and
CommutativeRing (the name has not been decided on yet) for commutative rings.
This is a big change and should happen with plenty of warning for the community. It would be convenient if a script could be made available to automate this.
There is currently a proposal to place all Oscar related repositories, or some subset of them in a single repository called OscarMono.jl. The details are not finalised and it is not known what impact this will have on Nemo. However, Nemo developers should be aware that this may happen at some point in the fairly near future.
Users of Nemo should be unaffected, as Nemo will continue to exist as a separate package in the OscarMono.jl repository, even if it does become part of this repository. Julia supports multiple packages in the same repository nowadays.
The possibility will always exist to separate the repositories again if the experiment is unsuccessful or serves its purpose and is no longer needed.
Moving implementations from Hecke
In the Hecke.jl project there are a vast number of implementations that were intended for AbstractAlgebra.jl and Nemo.jl. They exist in the
src/Misc directory of that project.
These implementations will eventually all be moved over to the correct repositories. Code, documentation and performance improvements will be added.
A number of things must be taken into account when making such moves:
Substantial chunks of code should be moved at a time. The code can be initially placed in a
src/Miscdirectory in AbstractAlgebra or Nemo until it can finally be integrated fully into the correct place in those projects.
Some of the code calls full parent object constructors in generic code. Such calls should be removed where possible.
Some functions such as
expand the like require
Baseto be prepended, as we do not import these functions from
Some of the code calls back into convenience functions found only in Hecke. These have to be rewritten in terms of AbstractAlgebra/Nemo functions.
Some of the code relies on
ZZRingElembeing available, but would otherwise be suitable for AbstractAlgebra. This code can hopefully be rewritten to be agnostic about the integer type.
Todos, questions and so on should be moved to tickets.
Sometimes exception types differ between Hecke and Nemo, meaning that tests will fail due to the wrong type of exception being raised. Either the tests will have to be adjusted, or the Nemo exception types changed.
RingElemis often used where
RingElementis intended, etc. Also types are often unconstrained where
Nemowould constrain them to
Some Hecke functions try to support generic types and specific concrete Nemo types in the same implementation. These will unfortunately have to either be split between AbstractAlgebra and Nemo or a completely generic implementation for abstract types will have to be made.
Some Hecke implementations assume
sub!and friends are available in generic code. These will have to be rewritten, usually by adding a single unary minus outside of a loop and switching to
add!and friends inside the loops.
Test code, docstrings and documentation will have to be added where they do not already exist.
Exports of the new functionality will have to be added.
Some functions should be accompanied by similar functions that don't yet exist. For example if there is a
blah_rowsthere probably should be a
blah_colsfunction as well, etc.