Add basic functionality for univariate Ore operators

[ooinaruhugh]

This pull request adds basic functionality for univariate Ore polynomials. This is implemented in pure Julia.
For now, this contains arithmetic capabilities and implements an interface similar or equal to NCPolyRing and such.

There are some minor additions that are technically required that would come with this PR.
Currently, there is no way to define a ring homomorphism of fraction fields (or function fields for that instance).
They are a rather common choice for coefficient fields of Ore algebras, that's why they are of interest.
Since for fraction fields of polynomial rings, the notion would naturally extend, I also introduce a type PolyFracFieldAnyMap that mimics PolyRingAnyMap.

I would keep this PR at this scope since this is also the point where we fix the interface for Ore algebras
which will be relevant as soon we make use of the implementation in FLINT for some specialised cases.

[ooinaruhugh]

As long as this is a draft, I am ignoring some style rules. I didn't sort the exports.jl so I don't lose track of what I've added

[lgoettgens]

Suggested change

	function PolyFracFieldAnyMap{D,C,V}(d::D,ϕ::V) where {D,C,V}
	return new{D,C,V}(d,ϕ)
	end
	function PolyFracFieldAnyMap{D,C,V}(d::D,phi::V) where {D,C,V}
	return new{D,C,V}(d,phi)
	end

please do not use unicode in variable names, see https://docs.oscar-system.org/dev/DeveloperDocumentation/styleguide/#Unicode

[thofma]

I have been playing around with some skew polynomial rings lately and so would also be interested in this functionality. I think this implementation here looks good. There are a few things I think would be worth discussing:

• Can we call the types OrePolyRing and OrePolyRingElem? This is just about the types. For the functions constructing the ring, we probably want aliases like ore_extension, skew_polynomial_ring or ore_polynomial_ring.
• We probably want to make ring parametrized by the type of the skew derivation:

@attributes mutable struct OrePolyRing{T<:RingElem, S, [U]}
  base_ring::Ring
  D::Symbol
  δ::S
  [sigma::U]

This has the advantage, that we can dispatch on the type S, for example, in the arithmetic. In my applications, $\sigma$ is always trivial and I think the implementation can be sped up in this case. In this regard, it might also be good idea to put the sigma in there (although it is a bit redundant).

• We probably want to support both R[x; sigma] and R[x; delta] (where in the first case delta = 0 is implied).

I really like the Sage interface: https://doc.sagemath.org/html/en/reference/noncommutative_polynomial_rings/sage/rings/polynomial/ore_polynomial_ring.html

[ooinaruhugh]

Can we call the types OrePolyRing and OrePolyRingElem? This is just about the types. For the functions constructing the ring, we probably want aliases like ore_extension, skew_polynomial_ring or ore_polynomial_ring.

I mean, I'm not really attached to names or anything. At least, this one meshes better with the rest of AA.jl.

We probably want to make ring parametrized by the type of the skew derivation:

@attributes mutable struct OrePolyRing{T<:RingElem, S, [U]}
  base_ring::Ring
  D::Symbol
  δ::S
  [sigma::U]

That's how it looked like in a initial draft but then I took out the reference to sigma. The type of δ/delta already carries the information, its PolySkewDerivation{Type_of_(Co)domain,Type_of_Sigma} if you want to be precise.

This has the advantage, that we can dispatch on the type S, for example, in the arithmetic.

Otherwise, that's already happening with PolySkewDerivation, see next point, we can just take more advantage of it.

We probably want to support both R[x; sigma] and R[x; delta] (where in the first case delta = 0 is implied).

For sigma = id this already goes into a quicker code path which assumes that delta is some ring element times the usual derivative. (edit, because I accidentally deleted that paragraph)

I really like the Sage interface: doc.sagemath.org/html/en/reference/noncommutative_polynomial_rings/sage/rings/polynomial/ore_polynomial_ring.html

I am aware of that one.

[thofma]

Can you clarifiy whether this implementation here is specifically for ore extensions of univariate polynomial rings? You keep mentioning that PolySkewDerivation is the type for derivations.

In the arithmetic application I have in mind the ore extension is F[x; f], where F = GF(q) and f(a) = a^p is the Frobenius endomorphism of F and delta = 0. I don't quite understand how this is related to sigma = id.

[ooinaruhugh]

Can you clarifiy whether this implementation here is specifically for ore extensions of univariate polynomial rings? You keep mentioning that PolySkewDerivation is the type for derivations.

Sure, I was being a bit imprecise here, I did introduce SkewDerivation{D,S} with the type parameters being D for the type of the domain and S for the type of sigma. PolySkewDerivation{D,S} is then the subtype of that for derivations on univariate polynomial rings (and their fraction fields).

That said, this implementation is for univariate Ore extensions, in the sense of a single indeterminate that commutes according to sigma and delta. So far I only had polynomial rings (and their fraction fields) for coefficient rings in mind, but that's due to my lack in imagination.

But this implementation doesn't care about this as long as you can define sigma as a Map{D,D,...} like with hom and a delta. All the functionality will just apply sigma and delta to the coefficients where necessary.

In the arithmetic application I have in mind the ore extension is F[x; f], where F = GF(q) and f(a) = a^p is the Frobenius endomorphism of F and delta = 0. I don't quite understand how this is related to sigma = id.

I mean, two big families of Ore extensions people care about are those with delta = d/dx or delta = r * d/dx and sigma = id where R is a polynomial ring or sigma something and delta = 0. What this implementation does to evaluate the former case is to apply the "skew Leibniz rule" recursively. For PolySkewDerivation{D,S} where S is the type of the identity map, I just call derivative immediately.

Again, thinking only of univariate polynomials as coefficients was me not thinking hard enough of more examples.
I'm glad you brought up the arithmetic example. I need to look into how much we can bend AA into defining the necessary delta as some sort of map. I suppose in that case I would just have to allow FunctionalMap or sth.

EDIT: I suppose suitable sigma, not delta in your case. That's essentially what trivial_derivation does.

[thofma]

Thanks for the explanation. Yeah, trivial_derivation sounds about right. I would probably go with a generic

struct TrivialSkewDerivation{D, S} <: SkewDerivation{D, S}
  domain::D
  sigma::S
end

then in my example I could

ore_extension(GF(9), trivial_deriviation(GF(9), frobenius))

Then one could add special methods for *, where the derivation is of type TrivialSkewDerivation. Would you be happy with such a thing?

Are you currently working on this? If not, do you mind if I push a few things to make the arithmetic example work?

[ooinaruhugh]

Thanks for the explanation. Yeah, trivial_derivation sounds about right. I would probably go with a generic

struct TrivialSkewDerivation{D, S} <: SkewDerivation{D, S}

  domain::D

  sigma::S

end

then in my example I could

ore_extension(GF(9), trivial_deriviation(GF(9), frobenius))

Then one could add special methods for *, where the derivation is of type TrivialSkewDerivation. Would you be happy with such a thing?

Are you currently working on this? If not, do you mind if I push a few things to make the arithmetic example work?

I mean, yeah, I'm working on the code right now. But if you have something written down already, sure, go ahead.

Even then, I would appreciate the examples for test cases.