Homomorphisms for Polynomial rings over generic coefficient rings can not be defined

[HechtiDerLachs]

The following code produces an error:

R, (x,y) = QQ["x", "y"]
Y = Spec(R)
Q = OO(Y)
T, (u,v) = PolynomialRing(Q, ["u", "v"])

f = AlgebraHomomorphism(T, T, [u^2, v^2])

Again, this is due to an invocation of singular_ring, in this case in https://github.com/oscar-system/Oscar.jl/blob/14d1008a4e1b63d71d5e5572b95c0b00f0a7fde2/src/Rings/affine-algebra-homs.jl#L115 It seems that these singular invocations are still abundant and block the use of the code for generic purposes.

[HechtiDerLachs]

@ederc @thofma : Thanks for the fix of the ideals issue! That works now. But, as it seems, the overall problem is not solved, yet.

[thofma]

What is the "overall problem"?

[HechtiDerLachs]

That when developing the code for ideals, modules, homomorphisms, etc. the developers had in mind computations in polynomial rings with a ring of coefficients, that singular can digest. But that's not necessarily the case; at least not in the applications that I have in mind now. Now the supposedly generic code for polynomial rings does not run, because invocations of singular are made in places where the coefficient ring can not be translated.

I assume that polynomial rings, their ideals and modules should be working over arbitrary computable/exact/... coefficient rings, right? By 'working' I just mean: One should be able to declare and instantiate them and the arithmetic should be working. Whether I can do further useful things with them is on a different page for now.

If I am mistaken and I have a wrong understanding of what generic polynomial rings in Oscar should be capable of, please correct me!

[fieker]

On Thu, Jan 20, 2022 at 04:47:51AM -0800, Matthias Zach wrote:

That when developing the code for ideals, modules, homomorphisms, etc. the developers had in mind computations in polynomial rings with a ring of coefficients, that singular can digest. But that's not necessarily the case; at least not in the applications that I have in mind now. Now the supposedly generic code for polynomial rings does not run, because invocations of singular are made in places where the coefficient ring can not be translated.

I assume that polynomial rings, their ideals and modules should be working over arbitrary computable/exact/... coefficient rings, right? By 'working' I just mean: One should be able to declare and instantiate them and the arithmetic should be working. Whether I can do further useful things with them is on a different page for now.

If I am mistaken and I have a wrong understanding of what generic polynomial rings in Oscar should be capable of, please correct me!

You're partly correct. Over generic exact rings I can hardly do anything structural. Arithmetic and polynomial arithmetic (ring operations only) are possible. Of course, I can define (or could define) an ideal, but for all operations I need to have more, namely some form of normal form. Be it rref (hnf) or std, syz, ... I do not (so far) see the point of having ideals if I cannot do anyhting with them...

Question: what are you trying to do with your structures?

-- Reply to this email directly or view it on GitHub: https://github.com/oscar-system/Oscar.jl/issues/1003#issuecomment-1017464591 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[HechtiDerLachs]

I would like to use them for bookkeeping.

Say, I have a vector bundle E -> X of rank r+1 over a scheme X and I want to model the associated projective bundle IP(E). Then locally over suitable open subsets U of X, I have a graded polynomial ring S = O(U)[s_0,...,s_r]. Naturally, the transition matrix for the vector bundle has entries in O(U n V) on the overlap of two open sets U and V and there is an induced endomorphism of the associated graded rings. In order to store and maintain all this information, I would like to make use of polynomial rings over generic coefficient rings, their ideals, and their morphisms.

As you can see, providing the arithmetic is totally sufficient for these purposes.

[fieker]

On Thu, Jan 20, 2022 at 05:28:32AM -0800, Matthias Zach wrote:

I would like to use them for bookkeeping.

Say, I have a vector bundle E -> X of rank r+1 over a scheme X and I want to model the associated projective bundle IP(E). Then locally over suitable open subsets U of X, I have a graded polynomial ring S = O(U)[s_0,...,s_r]. Naturally, the transition matrix for the vector bundle has entries in O(U n V) on the overlap of two open sets U and V and there is an induced endomorphism of the associated graded rings. In order to store and maintain all this information, I would like to make use of polynomial rings over generic coefficient rings, their ideals, and their morphisms.

As you can see, providing the arithmetic is totally sufficient for these purposes.

What do you want to do with the ideals? Generically, I can do

• printing
• plus
• times

  -- Reply to this email directly or view it on GitHub: https://github.com/oscar-system/Oscar.jl/issues/1003#issuecomment-1017504683 You are receiving this because you commented.

  Message ID: @.***>

[HechtiDerLachs]

Besides: On a first read, one has the impression that generic polynomial rings are available in Oscar and people have put some effort into implementing them. The Ring interface test even tests the functionality. And also for modules, ideals, and homomorphisms, I don't see why the part that is working generically in theory should not also work generically in practice. Once one invokes a more complicated procedure such as computation of ideal membership, kernels, etc. it can still complain about missing implementations.

As far as I understand, the problem with the ideals was just that some singular routine was unnecessarily called in a too early stage. We have the capsulation into the singular_assure methods already and if this is consistently applied, I think there shouldn't be a problem. It just seems to me that by accident, some calls are still in the wrong place and some more code should be cleaned up a little.

[HechtiDerLachs]

What do you want to do with the ideals? Generically, I can do - printing - plus - times

And isn't that already enough to provide them? If that recent fix had not been provided, I would have to even implement these things manually for some stored list of generators.

[thofma]

I think this is a valid issue and we should try to call into Singular only when necessary and only when we are sure it will work.

[tthsqe12]

I think the singular invocations are currently there in case you want to do stuff like kernel or preimage with the resulting homomorphism.

[fieker]

On Thu, Jan 20, 2022 at 05:37:57AM -0800, Matthias Zach wrote:

Besides: On a first read, one has the impression that generic polynomial rings are available in Oscar and people have put some effort into implementing them. The Ring interface test even tests the functionality. Done and working. And also for modules, ideals, and homomorphisms, I don't see why the part that is working generically in theory should not also work generically in practice. Once one invokes a more complicated procedure such as computation of ideal membership, kernels, etc. it can still complain about missing implementations.
Difficult - and you're not the 1st to consider that. I was contemplating that, but gave up when I reaslised that

• yes, sub-quotients can be used for everything, but I don't want to use them always
• there are different, fundamentally different, versions for submodule elements:
• via elements of the ambient space
• via a local system of generators
• for rings with rref, I want to use it: never have modules with more than n generators, never have too large gens, ....
• for rimgs with std, I possibly want to be as lazy as possible so I gave up. Point being: rref is fast, std is slow, thus when rref is applicable you're going to reduce early and enjoy uniqueness. On the other hand, if std has to be used, you try to avoid any call like the plague.

Lifting restrictions on the creation of MPolyIdeal: fine with me. Free modules can be done over any ring as well. Working with sub and quo not.

As far as I understand, the problem with the ideals was just that some singular routine was unnecessarily called in a too early stage. We Well, unneccessary... for me it was used to check isone, iszero on elements to have nice printing... have the capsulation into the singular_assure methods already and if this is consistently applied, I think there shouldn't be a problem. It just seems to me that by accident, some calls are still in the wrong place and some more code should be cleaned up a little. Definitely.

-- Reply to this email directly or view it on GitHub: https://github.com/oscar-system/Oscar.jl/issues/1003#issuecomment-1017512698 You are receiving this because you commented.

Message ID: @.***>

[HechtiDerLachs]

Difficult - and you're not the 1st to consider that. I was contemplating that, but gave up when I reaslised that - yes, sub-quotients can be used for everything, but I don't want to use them always - there are different, fundamentally different, versions for submodule elements: - via elements of the ambient space - via a local system of generators - for rings with rref, I want to use it: never have modules with more than n generators, never have too large gens, .... - for rimgs with std, I possibly want to be as lazy as possible so I gave up. Point being: rref is fast, std is slow, thus when rref is applicable you're going to reduce early and enjoy uniqueness. On the other hand, if std has to be used, you try to avoid any call like the plague. Lifting restrictions on the creation of MPolyIdeal: fine with me. Free modules can be done over any ring as well. Working with sub and quo not.

First of all: I don't understand what you refer to when you say 'rref'. Is this an abbreviation for a set of algorithms?

Regarding the rest: We will need to implement localizations of modules, soon. This is just one example where it will be favourable, to have a unified framework for finitely presented modules already set up, including names for the common getters/setters/constructors, etc. Of course, for subquos this will be nothing but an empty hull, since one can not even check equality of elements. But then the developer who wishes to use these with other rings than polynomial rings over a field, has to implement the functionality by themselves via dispatch for the type-parameters. In my opinion, it would be great if we could provide a nice and clean cut there and communicate to the developer where they can start with their individual implementation.

I don't really understand where the problem with the different ways of storing subquos really lays. Can't you always store elements as linear combinations of the generators? Maybe this becomes cumbersome, indeed. But I don't really see why, at this point.

Either way: I would like to be able to add and scalar-multiply in free modules over polynomial rings over any ring and also compose homomorphisms, etc, simply for the bookkeeping reasons above.